Remote authentication and transaction signatures

ABSTRACT

Authentication devices and methods for generating dynamic credentials are disclosed. The authentication devices include a communication interface for communicating with a security device such as a smart card. A dynamic credential such as a one-time password (OTP) or a message authentication code (MAC) may be generated by receiving from a server an encrypted initialization seed encrypted with an asymmetric encryption algorithm using a public key of a public/private key pair, submitting the encrypted initialization seed to a security device, decrypting at the security device the encrypted initialization seed with a private key of the public/private key pair, returning the decrypted initialization seed to the authentication device, deriving at the authentication device a secret credential generation key from the decrypted initialization seed, and generating the dynamic credential by combining a dynamic variable with the secret credential generation key using a symmetric cryptographic dynamic credential generation algorithm.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application Ser.No. 61/746,892 entitled Remote Authentication and TransactionSignatures, filed on Dec. 28, 2012, the contents of which areincorporated fully herein by reference.

BACKGROUND

As remote access of computer systems and applications grows inpopularity the number and variety of transactions which are accessedremotely over public networks such as the Internet has increaseddramatically. This popularity has underlined a need for security inparticular;

-   a. How to insure that people who are remotely accessing an    application are who they claim they are and how to insure the    transactions being conducted remotely are initiated by legitimate    individuals. This subject is referred to as authentication.-   b. How to insure that transaction data has not been altered before    being received at an application server. This is referred to as data    integrity.-   c. How to guarantee that an individual, once having engaged in a    transaction, is not in a position to repudiate it. This is referred    to as non-repudiation.

In the past, application providers have relied on static passwords toprovide the security for remote applications. In the last couple ofyears it has become evident that static passwords are not sufficient andthat more advanced security technology is required.

PKI Smart Cards

One way of solving the security problems associated with remote accessto computer systems and applications over public networks is provided bya Public Key Infrastructure. In a Public Key Infrastructure oneassociates a public-private key pair with each user. The key pair isassociated with a certificate (issued by a trusted CertificateAuthority) that binds that public-private key pair to a specific user.By means of asymmetric cryptography this public-private key pair can beused to:

-   a. authenticate the user,-   b. sign transactions, documents, e-mails (so as to prevent    repudiation), and-   c. set up encrypted communication channels.

To guarantee an adequate level of security it is mandatory that eachuser's private key remains secret and can only be accessed (e.g. tocreate a signature) by the legitimate user associated with that key. Itis common to rely on a smart card to store the public-private key pairand the certificate and to carry out the cryptographic calculationsinvolving the private key. The use of the private key by the card isthen often PIN-protected.

PKI-enabled smart cards are, and have been issued by:

-   a. Corporations to their employees or customers to secure the log-in    to their computer networks or the remote access to their    applications,-   b. Banks to their customers to secure e.g. Internet banking    applications, and-   c. Governments to their citizens as electronic ID cards to create    legally binding electronic signatures.

Apart from the advantages, there are also some disadvantages associatedwith PKI and the smart cards carrying the PKI keys and certificates:

-   a. Building a Public Key Infrastructure is generally quite    complicated and therefore expensive when compared to competing    security technologies.-   b. PKI is inherently limited to environments and applications where    there is a digital connection between clients and servers. In other    words it is unsuitable for telephone banking or other delivery    channels where it is not possible to provide a digital connection    between the container of the PKI certificate and private key on the    one hand and an application server on the other hand.-   c. PKI smart cards do not have a power supply or a user interface.    PKI smart cards therefore rely on the presence of an interfacing    device that provides electrical power to the card, that is capable    of digitally exchanging data with the card, and that is capable of    interfacing with the user (e.g. capturing the card's PIN and    presenting the data that should be signed). In most cases a PC with    a connected transparent smart card reader is used. This reduces the    mobility of the user (many PCs are not equipped with smart card    readers). It also presents a security problem: all user interaction    (such as approving a signature or capturing the card's PIN) is done    on the inherently insecure PC.    Strong Authentication Tokens

An alternative technology for authentication and transaction signaturecapabilities is offered by what are called ‘strong authentication tokendevices’. A typical example of strong authentication token is any one ofthe Digipass tokens offered by Vasco Data Security Inc., see the websiteVasco.com.

A strong authentication token is a small autonomous battery-powereddevice with its own display and keyboard. In some cases the keyboard isreduced to a single button or even completely omitted. The main purposeof a strong authentication token is to generate so-called ‘One-TimePasswords’ (OTPs). In some cases strong authentication tokens are alsocapable of generating electronic signatures or Message AuthenticationCodes (MACs) on data that has been entered on the token's keyboard. Ifthe token has a keyboard, the usage of the token is often protected by aPIN.

To be able to generate OTPs or MACs, strong authentication tokens arecapable of doing cryptographic calculations based on symmetriccryptographic algorithms parameterized with a secret value or key.Typical examples of such symmetric cryptographic algorithmsparameterized with a secret value or key are symmetricencryption/decryption algorithms (such as 3DES or AES) and/or keyedone-way hash functions (such as MD5 or SHA-1 in OATH compliant tokens).In the remainder of the text the output of such algorithms willsometimes be referred to as ‘symmetric cryptogram’. The terminology‘symmetric cryptogram’ shall thus be understood as not only the outputof a symmetric encryption algorithm but also of symmetric decryptionalgorithms or keyed hash functions. Strong authentication tokens arepersonalized with one or more secret keys that are supposed to bedifferent for each individual token. To generate a one-time password orsignature, the token typically performs the following steps (refer toFIG. 1):

-   a. Step 10: The token takes one or more input values (these could    include a challenge generated by a server and typed-in on the    keyboard by the user, and/or the value of the token's internal    real-time clock, and/or the value of an internal counter managed by    the token, and/or transaction data typed-in on the token's keyboard    by the user).-   b. Step 11: The token puts the one or more input values into a    specified format.-   c. Step 12: The token then cryptographically combines the one or    more input values with a personalized secret key 15 stored securely    in the token. In a typical strong authentication token the token    submits the one or more input values to a symmetric    encryption/decryption algorithm and/or one-way hash function    parameterized by a personalized secret key 15 stored securely in the    token. The result is a cryptogram or a hash value.-   d. Step 13: The token transforms the cryptogram or hash value that    is the outcome of this encryption/decryption or one-way hash (or    more generally, some other cryptographic combination) into the    actual OTP or MAC. i.e., the cryptogram or hash is typically    truncated, converted in a human readable format (e.g. through    decimalization) and visualized on the display. The user may submit    this value to the application server.    In the remainder of the text one-time passwords or electronic    signatures generated by strong authentication tokens as described    above may be referred to as dynamic authentication credentials or    just dynamic credentials. In the remainder of the text the input    values referred to in step 10 may be referred to as dynamic    variables. Dynamic variables the value of which comes from a source    that is external to the strong authentication token may be referred    to as external dynamic variables. Examples of external dynamic    variables may include a challenge or transaction data that e.g. may    be provided to the token by a user entering them on the token's    keyboard. Dynamic variables the value of which comes from a source    that is internal to the strong authentication token may be referred    to as internal dynamic variables. Examples of internal dynamic    variables may include a time-value that is provided by a token's    real-time clock or a counter that is stored in a token's memory and    updated by the token's processor. The algorithms published by the    “OATH—initiative for open authentication” are an example of    standardized algorithms for generating dynamic credentials.

In most cases a strong authentication token is a physical device,however in some cases the functionality of these strong authenticationtokens to generate OTPs or MAC signatures is emulated by softwarerunning on a PC, a workstation, a mobile phone, a personal organizer, aPDA, etc. The latter are referred to as “soft tokens”.

Once the OTP or MAC has been produced it is conveyed to an entity wherethe value can be verified as authenticating the user or the message, seeFIG. 2. Typically the entity is an application server. The applicationserver stores data for each token, including which secret key(s) thetoken has been personalized with, and the identity of the userassociated with the token. To validate a one-time password or signature,the server retrieves the secret key (115) which is a copy of the keypersonalized in the token, takes the same inputs that were used by thetoken and in essence performs the same algorithm 112 as the token. Theserver then compares 120 the result it obtained with the value itreceived. (In practice, the validation of an OTP or MAC is oftensomewhat more convoluted if the strong authentication algorithm istime-based or counter-based, due to synchronization issues.) Since aone-time password or signature generated by a strong authenticationtoken is a function of the token's individual secret key and the alwaysdifferent values of the input(s) to the token algorithm, validating thecorrectness of the one-time password or signature gives the applicationserver a very high degree of confidence that the person submitting theone-time password or signature possesses the correct token and knows itsPIN (if the token is PIN protected), which in turn gives a high degreeof confidence that that person is indeed the legitimate user associatedwith that token device.

Because the OTP verification server and the OTP token in essence performthe same algorithm with the same key, the OTP generation algorithm canbe a one-way or non-reversible function. That means that the actual OTPcan be shorter than the cryptogram or hash value from which it isderived. This allows for OTP or MAC lengths that are sufficiently shortso that it is not too inconvenient for users to manually copy the OTP orMAC values from the token display onto a PC. As a consequence strongauthentication tokens don't require a digital connection between thetoken and the verification server.

The major advantages of strong authentication tokens when compared toPKI cards are:

-   a. They are fully autonomous (tokens have their own power supply and    their own user interface);-   b. They are independent of the delivery channel or communication    medium (tokens don't require any digital or electronic connection    with any other device; all input and output of data is done by the    user via the token's display and keyboard); and-   c. They offer a very high level of security (all user interaction    such as capturing the PIN or providing transaction data to be signed    is done via the token's own secure user interface).

In some cases where smart cards have been issued, one wants to getaround the disadvantages and limitations associated with smart cards andachieve the same advantages that strong authentication tokens offer i.e.full autonomy, independence of the delivery channel, and a secure userinterface.

One alternative is to combine the smart card with an unconnected,battery-powered smart card reader that has its own display and keyboard.The idea is that the combination of the smart card and the unconnectedsmart card reader emulates a strong authentication token. Thefunctionality normally provided by a strong authentication token is thensplit over the smart card and the unconnected reader. The unconnectedreader takes care of all user interface, and all or a part of the othertoken functionality is delegated to the card.

Typically, all personalized secrets and security sensitive data arestored and managed by the card (e.g. the PIN is stored and verified bythe card, the secret keys are stored on the card and all cryptographicoperations involving those keys are done by the card, counters used asinput for the token algorithm are stored and managed by the card). Partof the token functionality that is less sensitive (e.g. truncating andconverting the generated hashes or cryptograms) often happens in thereader. An example of this combination is discussed below.

This principle is often used by banks that combine the bank cards theyissue (for usage at Automatic Teller Machines or Point Of Saleterminals) with unconnected readers to secure their remote bankingapplications (such as internet banking or telephone banking). A goodexample of this is the Mastercard Chip Authentication Programme (CAP),which specifies how EMV smart cards can be used in combination withunconnected smart card readers to generate one-time passwords andelectronic transaction data signatures.

This technology relies on the smart cards being capable of doingsymmetric cryptographic operations and having been personalized with asecret key to be used for symmetric cryptographic operations. However,PKI-enabled smart cards are designed to store asymmetric keys and doasymmetric cryptographic operations. Many PKI-enabled smart cards don'tsupport symmetric cryptographic operations or (if they do) have neverbeen personalized with an individual symmetric secret key.

Traditional PKI Signatures

The usual way to create an electronic signature with a PKI smart card,is that the input data (usually, the input data consist of a hash of theactual transaction data one wants to sign) are encrypted by the card'sprivate key.

The usual way to validate such a signature, is that the validatingentity decrypts the received signature with the public key. If thedecryption of the signature results in the same value as the input datathat were supposed to have been encrypted by the private key, thesignature is validated successfully. Note that thanks to this asymmetriccharacteristic the validating entity never needs to have access to thecard's private key. This allows the private key to be kept secret fromany party other than the signing party, even from any verifying party,thus providing for true non-repudiation.

This can only be done successfully if the signature itself is in itsentirety available to the validating entity. The decryption of anincomplete signature would only result in meaningless data that can notbe compared with the input data that were supposed to have been signed.

This condition can not be fulfilled in practice when small hand-heldunconnected smart card readers are being used: given that a typical PKIsignature size is in the order of 100 bytes, the display of thesereaders is far too small to display a full signature and it is in anycase totally unrealistic to expect a user to manually transfer a100-byte value from the reader's display to a PC without making a singlemistake. The 100-byte typical PKI signature should be compared to atypical 6 to 8-digit or 3 to 4-byte OTP or MAC of a traditional strongauthentication token. This is certainly a reason why asymmetriccryptography and private keys have not been used to generate OTPs andMACs by e.g. strong authentication tokens.

The inventors have determined that methods and apparatus are neededthat:

-   -   a) allows the usage of a device storing PKI private keys (such        as PKI-enabled smart cards or USB sticks) to authenticate users        and to sign transactions,    -   b) without the need for any user application to have some kind        of a direct or indirect digital connection with the device        containing the private key, in particular a digital connection        that would allow the user application to submit data to the card        for signing by the card's private key and that would allow        retrieval of the entire resulting signature from the card should        not be necessary,    -   c) without the need for the PKI-enabled device containing the        private key (e.g. a PKI smart card or USB stick) to:        -   1) either support symmetric cryptographic operations, or        -   2) to have been personalized with some secret or            confidential data element that can be read by a suitable            reader.

SUMMARY OF THE INVENTION

This application provides a description of a method and apparatus whichmeets the foregoing desire. In particular this application describes anumber of embodiments which use the private key of a public-private keypair (a key which is meant to be used for asymmetric cryptography suchas for example the RSA algorithm) to authenticate a user (via generationof a OTP) or to sign data (via generation of a MAC).

The embodiments described here differ from the traditional use ofprivate keys to authenticate users and sign data (as described above) inthat:

-   -   a) the same cryptographic key is used to generate and verify the        OTPs and MACs; and    -   b) the length in bits of the OTP and MAC values can safely be        considerably less than the length in bits of the cryptograms        generated by the private keys.

All embodiments have in common that:

-   -   a) They all calculate a dynamic value using one or more variable        inputs by means of a cryptographic algorithm that uses a secret        that is also known or accessible to a verifying server.    -   b) These variable inputs can be, for example, any of:        -   1) Time value, or        -   2) Counter value, or        -   3) Challenge value, or        -   4) Transaction Data, or        -   5) Any combination of the above.    -   c) The dynamic value is then transformed into an OTP or MAC.    -   d) At some point in the course of developing the OTP or MAC an        asymmetric cryptographic operation with a private key (i.e. an        encryption/decryption or a signature) is carried out.    -   e) The transformation of the dynamic value into an OTP or MAC is        such that the length or size of the OTP or MAC is smaller than        the size of the cryptogram that was generated by the asymmetric        cryptographic operation with the private key.

The precise role of the asymmetric cryptographic operation with theprivate key in the overall process of generating the OTP or MAC can bedifferent from one embodiment to another.

In some embodiments the asymmetric cryptographic operation with theprivate key is performed each time an OTP or MAC has to be generated. Inother embodiments more than one OTP or MAC can be generated inconnection with a single asymmetric cryptographic operation with theprivate key. In the latter case, criteria that can determine whether ornot a new asymmetric cryptographic operation with the private key isrequired when a new OTP or MAC needs to be generated can include:

-   -   a) The time that has passed since the last asymmetric        cryptographic operation.    -   b) The number of OTPs and/or MACs that have already been        generated.    -   c) Whether or not a communication session between a device        containing the private key and a device capturing the inputs and        making available the OTPs has been uninterrupted (e.g. whether a        PKI smart card has not been removed from a smart card reader).    -   d) The type of OTP or MAC. For example the generation of a MAC        might always require a new asymmetric cryptographic operation        but the generation of an OTP would not.

In a typical embodiment only one private key is used and only oneasymmetric cryptographic operation is performed with that private key.However, some embodiments may perform a number of cryptographicoperations with either a single private key or with a number of privatekeys. Examples:

-   -   a) If the OTP is a function of the encryption result of the        variable inputs by a private key, then a variant could be that        the OTP is a function of more than one cryptogram, or that the        variable inputs are encrypted by more than one private key to        generate the OTP.    -   b) If the generation of an OTP only takes place after the        presence of a specific smart card is verified by checking the        result of an encryption of a challenge by the card's private        key, then a variant could be that more than one challenge is        submitted to the card to be encrypted by the card's private key.    -   c) In many cases a PKI card contains a so-called utility private        key and a signature private key. In that case the utility key        might be used if an OTP is generated and the signature key might        be used if a MAC is generated.

In a preferred embodiment both OTPs to authenticate a user and MACs tosign data can be generated. However alternative embodiments can belimited to only being capable of generating OTPs or only being capableof generating MAC signatures.

In a typical embodiment the asymmetric cryptographic algorithm used withthe private key will be the RSA algorithm. However, other embodimentscan use other asymmetric algorithms provided they are capable of eitherencryption or decryption or signing functionality by using the privatekey. Examples of such algorithms include: RSA, knapsack algorithms suchas Merkle-Hellman or Chor-Rivest, Pohlig-Hellman, Diffie-Hellman,ElGamal, Schnorr, Rabin, Elliptic Curve cryptosystems, Finite Automatonpublic key cryptosytems, the Digital Signature Algorithm (DSA, DSS).

In a typical embodiment the component that contains the private key andthe component that generates the OTP and MAC values are two differentcomponents, each being a part of two different devices. However,embodiments can easily be conceived in which these two components areparts of the same device or are even the same component.

In a typical embodiment the private key is stored on a smart card. In apreferred embodiment the cryptographic calculations involving theprivate key are performed by that smart card. In a typical embodimentthe OTP and/or MAC values are generated by a device that is equippedwith or connected to a component or device that can communicate with thesmart card containing the private key.

In a preferred embodiment the card reading device is an unconnectedsmart card reader with its own power supply and running the appropriatesoftware to communicate with a PKI smart card which has been insertedinto the smart card reader to generate OTPs or MACs.

In another embodiment the card reading device is the combination of somecomputing device such as a PC, PDA, cell phone, etc., equipped with asmart card reader and running the appropriate software to generate OTPsor MACs.

In a typical embodiment the physical, electrical and protocol aspects ofthe communication between the smart card and the smart card readingdevice is the same or similar to those described in the ISO 7816standard. Other embodiments could use another communication interfacesuch as a contactless smart card interface as described in ISO 14443.

Alternative form factors are available for the private key containingdevice, as well as alternative form factors for the OTP or MACgenerating device, and alternative means for the communication betweenthe private key containing component or device on the one hand and theOTP and MAC generating component or device on the other hand. Thesealternatives are within the scope of the invention as described herein.

In one embodiment the OTPs or MACs values are visualized on a display ofthe card reading device. An OTP can e.g. consist of a series of symbols.In a typical embodiment these symbols are decimal digits. In otherembodiments these symbols can for example include:

-   -   a) hexadecimal digits, or    -   b) base 64 digits, or    -   c) characters from a writing system such as an alphabet, or    -   d) pictograms.

In one embodiment the generated OTPs or MACs are communicated to theuser by means of audible signals. For example the OTP can be a string ofdigits or characters or words that each have a characteristic associatedtone or that are read by a text-to-speech converter.

In one embodiment the generated OTPs or MACs are directly communicatedto an application by some electronic wired or wireless communicationmechanism. This mechanism can include a USB connection or an infraredconnection or a Near Field Communication connection or an RF connectionor a Bluetooth connection.

Other output mechanisms for the OTPs or MACs can be provided. In someembodiments the private key-based function is PIN protected.

The following description describes the basic embodiments in moredetail. In some embodiments the card's private key-based function isdirectly or indirectly used in the OTP or MAC generation. Either

-   -   a. an asymmetric cryptographic operation involving the card's        private key is an integral phase or part of the transformation        of the variable inputs into an OTP or MAC (Using the asymmetric        algorithm in a symmetric way), or    -   b. the card's private key-based function is used more indirectly        to provide a seed value that is used to derive a secret        symmetric key that is used by the OTP or MAC generation        algorithm. (Using an asymmetric cryptogram as a seed to derive a        secret key).

In some of the embodiments the value of the OTPs and/or MACs is afunction of the actual value of the card's private key. In yet otherembodiments the card's private key-based function is used to unlock theOTP or MAC generation algorithm in the reader:

-   -   a. Either the card is linked to an already personalized reader        and recognized on the basis of stored challenge-response        pair(s), or    -   b. the card is authenticated by the reader through traditional        PKI certificate based verification.

In the embodiments described in the immediately preceding paragraph thevalue of the generated OTPs and/or MACs is not a function of the actualvalue of the card's private key.

Thus in one aspect the invention provides a method to generate asecurity value comprising a One-Time Password (OTP) or a MessageAuthentication Code signature (MAC) comprising:

obtaining an intermediate dynamic value created using one or morevariable inputs and a cryptographic algorithm employing at least onesecret;

transforming said dynamic value into said security value,

wherein an asymmetric cryptographic operation with a private key iscarried out producing a cryptogram, in order to transform said dynamicvalue, and

said transforming includes producing said security value of a size whichis smaller than the size of a cryptogram that was generated by saidasymmetric cryptographic operation.

In another aspect the invention provides a device generating a securityvalue comprising a One-Time Password (OTP) or a Message AuthenticationCode signature (MAC) using the method described immediately above.

In another aspect the invention provides a method of validating asecurity value provided by a user in order to authenticate the user ordata associated with the user, said security value comprising a One TimePassword or a signature comprising a Message Authentication Code; saidmethod comprising:

creating a reference cryptogram using a reference cryptographicalgorithm applied to one or more reference inputs using a server keyrelated to a PKI private key of an authentic user, the referencecryptographic algorithm and the one or more reference inputs selected asidentical to corresponding elements used in creating the security valueby the authentic user;

thereafter either

operating on said reference cryptogram alone by transforming saidreference cryptogram into a reference security value including producingsaid reference security value of a size which is smaller than the sizeof the reference cryptogram and effecting a comparison of said referencesecurity value and said security value, or

operating on both said reference cryptogram and said security value toproduce a modified reference cryptogram and a modified security value,said operation on said reference cryptogram identical, in part to anoperation carried out to create said security value, and effecting acomparison of said modified reference cryptogram and said modifiedsecurity value, and

determining validity of said security value from results of saidcomparison.

In still another aspect the invention comprises a computer readablemedium supporting a sequence of instructions which, when executedperform a method of generating a security value comprising a One-TimePassword (OTP) or a Message Authentication Code signature (MAC), saidmethod comprising:

-   -   obtaining an intermediate dynamic value created using one or        more variable inputs and a cryptographic algorithm employing at        least one secret;    -   transforming said dynamic value into said security value,    -   wherein an asymmetric cryptographic operation with a private key        is carried out producing a cryptogram, in order to transform        said dynamic value, and    -   said transforming includes producing said security value of a        size which is smaller than the size of a cryptogram that was        generated by said asymmetric cryptographic operation.

Finally in still another aspect the invention comprises an informationbearing signal comprising a sequence of instructions which, whenexecuted in a processor perform a method of generating a security valuecomprising a One-Time Password (OTP) or a Message Authentication Codesignature (MAC), said method comprising:

-   -   obtaining an intermediate dynamic value created using one or        more variable inputs and a cryptographic algorithm employing at        least one secret; transforming said dynamic value into said        security value,    -   wherein an asymmetric cryptographic operation with a private key        is carried out producing a cryptogram, in order to transform        said dynamic value, and said transforming includes producing        said security value of a size which is smaller than the size of        a cryptogram that was generated by said asymmetric cryptographic        operation.

BRIEF DESCRIPTION OF THE DRAWINGS

Several embodiments of the invention are now further described in thefollowing portions of the specification when taken in conjunction withthe attached drawings in which:

FIG. 1 is a flow diagram of the operation of a prior art strongauthentication token in generating an OTP of MAC;

FIG. 2 is a flow diagram of the operation of a prior art server inauthenticating an OTP or MAC generated by a strong authentication tokenand its relation to the OTP or MAC generation;

FIG. 3 is a flow diagram of an embodiment of the invention relying on anasymmetric cryptographic operation using a PKI private key to create acryptogram from which an OTP or MAC is generated;

FIG. 4 is a flow diagram of an embodiment of the invention showingOTP/MAC generation at the client (as in FIG. 3, for example) and therelated authentication at a server;

FIG. 5 is the flow diagram of another embodiment of the invention whichuses an asymmetric cryptogram as a seed to derive a key which is used increating a cryptogram representing an OTP or MAC;

FIGS. 6 and 7 are flow diagrams of still another embodiment of theinvention in which the smart card is used to authenticate the user tothe reader, which in turn produces a cryptogram from which an OTP or MACis derived, in this embodiment the user's smart card is bound to thereader in an initial operation (FIG. 6) and operation thereafter isrepresented in FIG. 7;

FIGS. 8 and 9 are flow diagrams of still another embodiment of theinvention in which the smart card, including a PKI certificate, is usedto authenticate the user to the reader, which in turn produces acryptogram from which an OTP or MAC is derived, in this embodiment arandom user may be authenticated;

FIGS. 10 and 11 illustrate actions taken in an initial session tocapture information allowing operation of various embodiments of theinvention;

FIG. 12 illustrates the context in which embodiments of the inventionoperate;

FIG. 13 is an illustration of a first validation procedure, and

FIG. 14 is an illustration of another validation procedure.

FIG. 15 is a diagram of one embodiment of a PKI device;

FIG. 16 is a diagram of an embodiment of a reader;

FIG. 17 represents the data employed in a protocol for creating adynamic authentication credential in accordance with an embodiment ofthe invention;

FIG. 18 illustrates the architecture of server side components to verifydynamic credentials according to an embodiment of the invention.

FIG. 19 illustrates a method for securing an application in accordancewith an embodiment of the invention.

FIGS. 20A and 20B illustrate a method for registering or enabling auser's private key in accordance with an embodiment of the invention.

FIG. 21 illustrates a method for generating dynamic credentials inaccordance with an embodiment of the invention.

FIG. 22 illustrates a method for verify a dynamic credential inaccordance with an embodiment of the invention.

FIG. 23 is an illustration of an authentication device receiving asecurity device in accordance with aspects of the invention.

FIG. 24 is a flow diagram of steps for generating OTPs and/or MACs forauthenticating users and/or transactions using an authentication deviceand a security device in accordance with aspects of the invention.

DETAILED DESCRIPTION

Important components of embodiments of the invention are illustrated inFIG. 12 as including a smart card reader 20 (or simply reader) and anauthentication server 30 (or simply server).

At a minimum the reader 20 includes an interface 28 to accept a smartcard and a power supply 27. Some readers also include one or more useroperable buttons or keys; this is represented in FIG. 12 by the keyboard25. As used herein a user inserts a smart card into the smart cardinterface 28. As a consequence of some operation carried out by thereader 20, information is generated by the reader. That information maybe a One-Time Password (OTP). If transaction data is input to the readerthe information which is generated may include a signature such as aMAC. The output information may be presented on a display, such as thedisplay 26. Alternatively the reader may be digitally connected to anetwork. In that event the information may be presented to anotherentity also connected to the network and the display 26 may beunnecessary. Typically the information which is generated by the reader20 is used to authenticate a person or a message. A person may beauthenticated by use of a smart card (proving possession of the card)and some other information (such as a PIN or other user data). Thereader accepts the smart card and other information and creates an OTP.The OTP is communicated to server 30. Alternatively the message issigned by the reader 20, producing a MAC and the MAC is communicated toserver 30.

Server 30 is typically implemented as a computer with processingcapability and a data base 35. The information generated by the readeris communicated to the server 30 via the data path 40. Data path 40 maytake various forms. Typically the user manually transfers informationfrom the display 26 to a client device that is connected to the server30. Alternatively data path 40 may comprise a digital path allowinginformation to be communicated from reader 20 to server 30. As anotheralternative the data path may carry audio information, such as atelephone circuit which carries the voice of a user enunciatinginformation presented to the user on the display 26; where theinformation may be an OTP or MAC. Data path 40 may carry optical signalsrepresenting the information generated at reader 20. In general datapath 40 is any path which can be used to communicate information fromthe reader 20 to the server 30. The server 30 accepts either the OTP orMAC and with the assistance of data in the data base 35 determineswhether to accept or reject the information as validating the identityof the user (OTP) or the authenticity of the message (MAC). Theparticular procedures and data which are used by the server 30 are moreparticularly described below. One output of the server 30 selects eitherthe accept or reject for status 36, reflecting either acceptance of theOTP as validating the authenticity of the user's claim of identity orthe validation of the MAC as authenticating the associated message.

Using the Asymmetric Algorithm in a Symmetric Way

In this embodiment (see FIG. 3) a smart card 100 cooperates with a smartcard reader 105. Smart card 100 stores a PKI private key 301 which isused in an asymmetric cryptographic operation. The card's privatekey-based function (i.e. an asymmetric cryptographic operation involvingthe card's private key such as signing or decrypting) is an integralphase or part of the process which produces the OTP or MAC.

Generation of the OTPs and/or MACs happens in the following way:

-   -   Step 99: Input values which will be used in later steps are        captured.    -   Step 101: the input(s) for the OTP or MAC generation algorithm        are transformed or formatted into an initial value.    -   Step 102: the initial value is signed or encrypted/decrypted by        the card's private key 301.    -   Step 103: the resulting cryptogram is transformed into an OTP or        MAC.

In the example of FIG. 3 the OTP or MAC is a function only of the resultof the asymmetric cryptographic operation. However, in other embodimentsthe OTP or MAC may also be function of other data elements includingvalues that are functions of the variable inputs but that are notfunctions of the private key 301.

In a typical embodiment the input(s) to the OTP or MAC generationalgorithm are the same or similar as the inputs for the strongauthentication algorithm(s) used in traditional strong authenticationtokens. In other words these inputs may be selected, for example, as a:

-   -   time value, or    -   challenge (typically provided by a server), or    -   counter value, or    -   transaction data, or    -   any combination of the above.

In some embodiments additional input(s) or parameter(s) to the OTP/MACgeneration algorithm can include, for example:

-   -   data identifying a device (e.g. a reader serial number). or    -   secrets stored in the device, or    -   user identification data, or    -   secret codes or secret values provided by the user.

Formatting these input(s) into the initial value, step 101 can includeoperations such as:

-   -   Concatenation, or    -   Hashing. or    -   encryption/decryption with a symmetric cryptographic algorithm        (e.g. using a secret key stored in the device or provided by the        user).

Transforming the resulting cryptogram into the final OTP or MAC value,step 103 can include, for example, the following operations:

-   -   hashing (possibly a keyed hashing using a secret key stored in        the reader 105 or provided by the user), or    -   encryption/decryption with a symmetric cryptographic algorithm        (e.g. using a secret key stored in the reader 105 or provided by        the user), or truncation, or    -   selection of certain bits, nibbles or bytes, or    -   decimalization. The latter may be accomplished by:        -   interpreting the string of bits to be decimalized as a large            binary representation of a number, or        -   dividing the string of bits to be decimalized in groups of            bits and mapping each group of bits onto a decimal digit. A            typical example is dividing the string of bits into nibbles            and mapping each nibble onto a decimal digit according to            the following rule. If the hexadecimal value of the nibble            is 0x0 to 0x9, take the decimal digit with the same value;            if the hexadecimal value of the nibble is 0xA to 0xF,            subtract a constant (between 0x6 and 0xA) and then take the            decimal digit with the same value as the result of the            subtraction, or        -   many other decimalization algorithms known to those skilled            in the art.

The validation phase is now described. In this embodiment the validatingserver has a copy of the private key 301 that was used to generate theOTP or MAC value and uses it to perform essentially the same algorithmas the algorithm to generate the OTP or MAC value. The validatingserver:

-   -   (refer to FIG. 4) somehow obtains or reconstructs or guesses the        value(s) of the data elements that were used as input(s) to the        OTP or MAC generation algorithm when the OTP or MAC was        generated:        -   in case of a time value, the validating server may have its            own clock that is synchronized with the clock used for            generating the OTP or MAC,        -   in case of a challenge, the challenge may have been            generated by the validating server itself or may have been            passed to the validating server by the application together            with the received OTP or MAC,        -   in case of a counter, the validating server may maintain its            own counter value synchronized with the counter value used            for generating the OTP or MAC,        -   in case of transaction data, these data may have been passed            to the validating server by the application together with            the received OTP or MAC;    -   the input(s) for the OTP or MAC generation algorithm are        transformed into an initial value.

The initial value is thereafter signed or encrypted/decrypted (402)using the copy of the private key 301 held by the validation server. Thevalidating server then compares (403) the resulting reference cryptogramwith the OTP or MAC value that was received. If the resulting referencecryptogram matches the OTP or MAC value that was received, the signatureis validated successfully. This comparison might be done in a number ofways:

the validation server might in some embodiments transform the referencecryptogram into a reference OTP or MAC value and compare the referenceOTP or MAC value with the received OTP or MAC value (e.g. by checkingwhether they are identical), or

the validation server might reconstruct, from the received OTP or MACvalue a part of the original cryptogram generated by the private key,and compare this partial cryptogram with the corresponding part(s) ofthe reference cryptogram,

or

the validation server might transform the reference cryptogram into afirst intermediate validation value, and transform the received OTP orMAC into a second intermediate validation value, and compare the firstand second intermediate validation values.

This can be illustrated by the following example (see FIG. 14). In thisexample the OTP or MAC is produced based on a cryptogram which is theresult of an asymmetric encryption using a private key 1308. The serverproduces a reference cryptogram which is also the result of anasymmetric encryption using a key 1324 which is a copy of the privatekey 1308. As shown in FIG. 14

-   -   the reader 1350 calculates the OTP or MAC from said original        cryptogram by:        -   selecting every first bit of every byte of said resulting            cryptogram (1355), and        -   concatenating said selected bits into a bit string (1356),            and        -   interpreting said bit string as the binary interpretation of            a number and obtaining the OTP or MAC by taking the decimal            representation of said number (1357)    -   the validation server validates this OTP or MAC as follows:        -   the server modifies the reference cryptogram by setting all            bits except every first bit of every byte to 1 (1364), and        -   the server interprets the received OTP or MAC as the decimal            representation of a number and obtains a bit string by            taking the binary representation of that number (1359), and        -   the server expands said bit string by replacing every bit of            said bit string by a byte that consists of the bit being            expanded appended with seven 1-bits (1360), and,        -   the server compares said expanded bit string with said            modified reference cryptogram (1365).

The parameters of this procedure (choosing one bit of every byte) isillustrative. Those skilled in the art will be able to select anappropriate parameter to suit their needs and context. In particular, atypical RSA cryptogram is about 100 bytes. Selecting one bit of eachbyte will produce 100 bits. At about 3 bits per decimal digit this willproduce about 30 decimal digits for the OTP or MAC which is morepractical than 300 decimal digits, but may still be considered awkward.In that event we can select one bit of every 40 bits for a total of 20bits or about 6 decimal digits. The same procedure for generating theOTP or MAC from a cryptogram (transforming by selecting some but not allbits of the cryptogram) can also be used in the event a symmetric key isused in lieu of the asymmetric key. A typical symmetric cryptogramincludes about 100 bits. In this case selecting one of every eight bitswill leave us with about 12 bits or 4 decimal digits. This may beconsidered too small a number to be safe from attack. To avoid thisproblem we merely use one of every 4 bits (instead of 1 of every 8) toleave us with about 25 bits or about 8 decimal digits.

An alternative validation procedure is illustrated in FIG. 13. Theprocedures of FIG. 13 are the same as the procedures of FIG. 14 inproducing the cryptogram on the client side (operation 1305) and thereference cryptogram on the server side (operation 1323). As shown inFIG. 13:

the cryptogram is transformed into the OTP or MAC by a sequence of twotransformations, first a transform A (1306) and then a transform B(1307)

the validation server subjects the reference cryptogram to an operation1325 to produce a modified reference cryptogram, operation 1325 isidentical to the operation of transform A,

the validation server also subjects the OTP or MAC to an operation(1327) which is the inverse of transform B to produce a modified OTP orMAC,

validation depends on a comparison (1328) of the modified OTP or MACwith the modified reference cryptogram.

As was the case for the validation procedure of FIG. 14, the techniqueof FIG. 13 can be used regardless of whether the cryptogram is producedwith a symmetric or asymmetric key.

In contrast to traditional PKI signature verification, the method ofFIG. 3 doesn't require the full signature to be available to the server(as was demonstrated in connection with either FIG. 13 or 14). Thesolution can offer a very high level of security, even if no additionalsecret codes or keys (provided by the user or stored in the device) arebeing used other than the private key.

However, the technique of FIG. 3 can only be used if the validatingserver has a copy of the card's private key when it has to validate anOTP or MAC. The whole point of PKI is exactly that, in order toguarantee true non-repudiation, the private key is never accessible toanyone other than the user associated with that key. In many cases thisis guaranteed by the card generating the private and public key pairon-board without any possibility of extracting the private key from thecard. In other cases the key pair is generated externally and theninjected into the card, but then procedures would normally ensure thatthe private key in the card personalization system is immediatelydestroyed after injection into the card and no copy of the private keyis allowed to exist outside the card. In other words, this method willin many cases not be a suitable solution.

Using an Asymmetric Cryptogram as a Seed to Derive a Secret Key (FIG. 5)

In the following embodiment, the requirement that the validation serverhas access to a copy of the private key at the time of validation iseliminated. In this embodiment an OTP/MAC is generated in the same wayas a traditional strong authentication token. All the steps of thisalgorithm (capturing the inputs, formatting the inputs, encrypting orhashing the formatted inputs, transforming the resulting cryptogram ofhash into an OTP/MAC) are performed by the reader 505. In thisembodiment the invention differs from conventional practice in how thereader 505 obtains the symmetric secret strong authentication key. Toobtain this secret symmetric authentication key, the reader 505 relieson an operation of the card 500 involving the card's private key 510.The main steps of a basic embodiment of this method are as follows:

-   -   1. If required (i.e. the card protects usage of the private key        by a PIN) the reader asks the user to enter the PIN and submits        that PIN to the card.    -   2. Assuming the card 500 accepts the PIN, the unconnected card        reader submits a fixed value to the card to be signed by the        private key. This fixed value is further referred to as the        ‘reader-to-card challenge’.    -   3. The card signs the given challenge with its private key and        returns the resulting cryptogram to the reader. This resulting        cryptogram is further referred to as the ‘card-to-reader        signature response’.    -   4. The reader uses the resulting cryptogram as a seed to derive        a symmetric secret key. This key is further referred to as the        ‘derived strong authentication secret key’.

The reader dynamically personalizes the strong authentication algorithm(that is entirely carried out by the reader) with that derived strongauthentication secret key. In other words the reader carries out thestrong authentication token algorithm using the derived strongauthentication secret key.

FIG. 5 illustrates a suitable embodiment showing the interaction ofreader 505 and card 500. The process may require the user to enter a PIN510 in order to unlock the card 500. This step is optional, but ifperformed, the PIN entered at 510 by the user is communicated 511 to thecard 500 to be tested. The card either accepts or rejects the PIN. Theresponse of the card 500 is tested, 512 and only if accepted does theprocess continue. Thereafter function 513 captures input values fromsome or all of the reader, the user or the card. Function 514 may formatsome or all of the input values. Some or all of these values, or others,may form a reader-to-card challenge 515 a which is sent (function 515)to the card 500. The card 500 uses the challenge 515 a by performing acryptographic operation with the card's private key 510. The resultingcryptogram, the card to reader signature response 516 a, is communicatedback to the reader, function 516. The response 516 a is then used as aseed to create a secret value or key 517 a via function 517. Key 517 ais termed a derived secret strong authentication key. The key 517 a isthen used in a cryptographic operation, at function 518 along with theformatted value provided by function 514. Finally the resultingcryptogram is transformed at function 519 to produce the OTP or MAC.

The ‘reader-to-card challenge’ 515 a could be any of the following:

-   -   1. A fixed value that is the same for all readers of a certain        batch.    -   2. A fixed value that is fixed for a given reader but that has a        different value for each reader.    -   3. A fixed value that is constant for a given user but that can        be different for different users and that is entered at least        once in the reader by the user. In practice it is very likely        that this value will be entered either every time the card is        used, or only the first time that a given card is used with a        certain reader and will then be remembered by the reader.    -   4. Static data stored on the card that can be read by the reader        (e.g. the public key and certificate, or a card serial number).    -   5. A combination of any of the above.    -   6. A value derived from any of the above. The derivation        optionally including the use of some reader secret.

The algorithm to derive the strong authentication secret key from the‘card-to-reader signature response’ could make use of the followingtechniques (among others):

-   -   1. Extracting bits of some data elements    -   2. Concatenating some parts of some data elements    -   3. Symmetric encryption/decryption algorithms (e.g. DES, AES, .        . . )    -   4. Hashing algorithms (e.g. SHA-1)

The algorithm to derive the strong authentication secret key 517 a fromthe ‘card-to-reader signature response’ 516 a could make use of thefollowing extra data elements besides the ‘card-to-reader signatureresponse’ 516 a:

-   -   1. A fixed value that is the same for all readers of a certain        batch.    -   2. A fixed value that is fixed for a given reader but that has a        different value for each reader.    -   3. A fixed value that is constant for a given user but that can        be different for different users and that is entered at least        once in the reader by the user.    -   4. Static data stored on the card that can be read by the reader        (e.g. data associated with the private key such as the public        key and certificate, or a card serial number).    -   5. A combination of any of the above.

This description only mentions the use of a single private key of asmart card and a single operation with that key; if the card containsmore than one private key the reader could submit the ‘reader-to-cardchallenge’ 515 a to each of these card private keys and combine theresulting ‘card-to-reader signature responses’ 516 a in the derivationof the ‘derived strong authentication secret key’ 517 a.

Similarly the reader could also submit different ‘reader-to-cardchallenge’ values 515 a to the card and combine the resulting‘card-to-reader signature responses’ 516 a in the derivation of the‘derived strong authentication secret key’ 517 a.

In yet another embodiment the reader does not rely on a single‘reader-to-card challenge’ 515 a and corresponding ‘card-to-readersignature response’ 516 a and ‘derived strong authentication secret key’517 a, but instead uses a set of ‘reader-to-card challenges’ 515 a andcorresponding ‘card-to-reader signature responses’ 516 a and ‘derivedstrong authentication secret keys’ 517 a. To obtain a ‘derived strongauthentication secret key’ 577 a the reader selects one of these‘reader-to-card 515 a challenges’ and submits it to the card. Which‘reader-to-card challenge’ 515 a is selected determines thecorresponding ‘card-to-reader signature response’ 516 a and ‘derivedstrong authentication secret key’ 517 a. This selection therefore musthappen in a way that is predictable to the validation server. The readercan e.g. cycle through the set of ‘reader-to-card challenges’ 515 a in afixed order or can select a ‘reader-to-card challenges’ 515 a dependingon the value of the input(s) to the strong authentication tokenalgorithm. A simple example of the latter method is that the strongauthentication token algorithm works in challenge-response mode and thatone specific digit (e.g. the last digit) of the challenge indicates theindex of the ‘reader-to-card challenge’ to be used.

Because the private key is different for each card, the derived secretkey will for a given challenge be specific to a given card. In otherwords, the secret key that is used in the strong authenticationalgorithm in the reader is function of the card (or more precisely: ofthe private key 510 in that card). That means that in principle oneneeds to have access to the correct card to be able to generate acorrect OTP.

In most cases the private key is PIN protected, so that in addition tohaving access to the correct card, one also needs to know the card's PINto be able to generate a correct OTP.

If the fixed value which the reader submits to the card to be signed bythe private key can be different for different readers, then one needsbesides the other elements (e.g. access to the correct card andknowledge of the card's PIN) also the correct reader. Note: such usageof a value that is different for different readers, effectively ‘binds’the reader to the card.

For the validation server to be able to validate the strongauthentication OTPs and/or MACs generated in this way, it must know thevalue of the derived strong authentication secret key 517 a. The servermust therefore know the card's signature response 516 a. The cardsignature response for a given card challenge is determined by thecard's private key 510 and cannot be calculated without access to theprivate key 510. One consequence of this is that the server must haveaccess to the card's private key 510 (directly or indirectly) at leastonce.

If the key pair is generated internally on the card this means that theserver needs access to the card at least once, so that the server cansubmit to the card the card challenge(s) that will be applicable forthis user and retrieve and store the card response(s) to thatchallenge(s) (indirect access to the private key). If the key pair isgenerated externally and then injected in the card, the server could usethe private key directly to encrypt the challenge(s) before the privatekey outside the card is destroyed.

Only then is the server able to calculate the corresponding derivedstrong authentication key from the encrypted card challenge. Thedisadvantage of this is that, in practice, either the user will have togrant the server access to his/her card during a sort of registrationphase, or (in case of external key generation) the server must beallowed to encrypt the challenge with the private key value before thatprivate key value is destroyed.

Another consequence is that in practice for a certain user, the derivedstrong authentication secret key must remain unchanged. Since thederived strong authentication secret key is derived from the card'ssignature response to a certain card challenge, that card challenge andthe corresponding ‘card-to-reader signature response’ must remain fixedfor a given user. The disadvantage of this is that, if an attackerobtains the value of the ‘card-to-reader signature response’ of acertain user, then that attacker could potentially make fake cards thatalways return that recorded ‘card-to-reader signature response’ valuewhen inserted in a reader.

Including reader specific or user specific data elements in thegeneration of the ‘reader-to-card challenge’ and/or the derivation ofthe ‘derived strong authentication secret key’ from the ‘card-to-readersignature response’ can make it harder for an attacker to obtain thevalue of the correct ‘card-to-reader signature response’ or to exploitthat value with a reader to generate in a fraudulent way correct OTPs orMACs.

Another way to make it harder for an attacker to obtain the correct‘card-to-reader signature response’ is to not rely on a single‘reader-to-card challenge’ and corresponding ‘card-to-reader signatureresponse’ and ‘derived strong authentication secret key’, but insteaduse a set of ‘reader-to-card challenges’ and corresponding‘card-to-reader signature responses’ and ‘derived strong authenticationsecret keys’ as explained above.

In the following embodiment, the requirement for the server to haveaccess at least once to the card to perform a private key operation iseliminated altogether.

In this embodiment, the value of the symmetric secret authentication keyis not dependent (directly or indirectly) on the value of the card'sprivate key. The symmetric secret authentication key is not derived froma seed that is generated by the card by means of an asymmetriccryptographic operation involving the card's private key. Instead thereader is personalized with the symmetric secret authentication key orwith secret data from which the reader can dynamically derive thesymmetric secret authentication key. With this symmetric secretauthentication key the reader can generate OTPs or MACs just like atraditional strong authentication token. Usage of the reader isprotected and reserved to the legitimate user by logically binding theuser's card to the reader. Once the user's card has been bound to thereader, the reader will only generate an OTP or MAC if the user insertsthe card that was bound to the reader. The card thus functions as anaccess key to unlock the personalized reader.

At first usage, the reader will request the user's card to be inserted.Upon insertion of the card, the reader binds itself logically to theinserted card in the following way. The reader determines and rememberssome specific individual characteristics of that card. Thesecharacteristics can include:

-   -   card serial number    -   card's public key and/or certificate    -   the card's response to a given challenge (where the response is        defined as the encryption of the challenge by the card's private        key. Note: this would typically require the user to submit the        PIN to unlock the private key). This challenge and the        corresponding card's response must be remembered by the reader.        The challenge can be:        -   a fixed over-all challenge (same for all cards and all            readers)        -   fixed challenge per reader        -   fixed challenge per card (e.g. randomly generated by the            reader upon first presentation of the card and then            remembered by the reader)        -   challenge provided by user        -   a combination of any of the above

An example of this operation is illustrated in FIG. 6. The reader 600awaits receipt of card data (function 616). The card provides some carddata 611 to the reader (function 610). When the reader receives the carddata 611, that data is stored (function 617).

If the user wants to generate a dynamic password or signature (see FIG.7), the reader asks for the card that was bound to that reader. Thereader checks whether the presented card is indeed the expected card.I.e. it will retrieve the characteristics of the presented card(function 710) and compare them with the stored characteristics of thecard bound to the reader (function 711). This step can include:

-   -   reading the card's serial number    -   reading the card's public key and/or certificate    -   submitting a (stored) challenge to the card for encryption by        the card's private key (which may require the user to provide        the PIN to unlock the private key) and receiving the card's        response.    -   Upon successful validation of the presented card, the reader        proceeds with performing the strong authentication algorithm as        an ordinary strong authentication token.

To strengthen the security, many variations are possible. The reader canderive the symmetric secret authentication key from:

-   -   a data element pre-personalized in the reader,    -   and/or a data element provided to the reader by the user,    -   and/or a data element that the reader reads from the card.

Preferably, these data elements are secret. Instead of using always thesame challenge and corresponding card response that was used andobtained when the card was bound to the reader, the reader can usemultiple pairs of challenges and corresponding responses. Variations onthis principle include:

-   -   When the card is bound to the reader, the reader generates and        submits more than one challenge to the card and remembers the        corresponding card responses. When the reader later on needs to        validate the card, it can submit any subset of these challenges        to the card and check whether the card's responses match the        stored responses.    -   When the reader has successfully validated the inserted card, it        can generate a new challenge and obtain a corresponding response        from the card. This new challenge-response pair can then be        remembered by the reader as an alternative or additional pair to        the already previously known challenge-response pair(s).    -   These two variations can be combined.

The principle of yet another embodiment (FIGS. 8 and 9) is as follows.On behalf of the server, the reader locally authenticates the user bymeans of a traditional certificate based authentication of the user'sPKI card.

If the user was successfully authenticated by the reader, the readergenerates an OTP or MAC (using a traditional strong authentication tokenalgorithm) that can be validated by the validation server. The user canthen submit this OTP or MAC to the server as proof that he has beensuccessfully authenticated by the reader.

The reader locally authenticates the user by means of the user'sinserted PKI card and using traditional PKI technology. In a typicalembodiment this can be done as follows (refer to FIG. 8):

-   -   1. The reader 800 validates the card's certificate 806 (or        certificate chain).        -   a. Note: this assumes that the reader has access to the            trusted public key of the (root) Certificate Authority. This            can be done by storing the trusted public key of the (root)            Certificate Authority in the reader.        -   b. Note: the reader 800 does not have to do an explicit            verification of the entire certificate (chain) starting from            the (root) CA public key each time the card is inserted in            the reader. Instead the reader 800 can do the entire            verification when a card 805 is inserted for the first time            into the reader. The reader can then store the verified            certificate or the certificate's public key or a reference            value derived from the verified certificate or public key            (e.g. a hash of the certificate or public key). If the card            805 is then re-inserted at a later time, the reader 800 no            longer has to do all the calculations associated with            certificate validation, but can just compare the certificate            on the card with the certificate or reference value stored            in the reader.    -   2. The reader 800 does a challenge-response authentication of        card's private key:        -   a. Reader (810) generates a challenge 811, e.g. typically a            random number or some other non-predictable value that is            e.g. derived from a time value or counter value with a            cryptographic algorithm using some secret stored in the            reader.        -   b. The user provides the PIN protecting the card's private            key.        -   c. The reader 800 submits the PIN to the card.        -   d. The reader 800 submits a random challenge 811 to card to            be encrypted by card's private key.        -   e. The card signs (815) the reader challenge with its            private key and returns response (=encrypted challenge 816).        -   f. The reader 800 decrypts card's response with card's            public key (from the certificate).        -   g. The reader compares 820 decrypted card's response with            originally generated challenge. If the decrypted card's            response is the same as the originally generated challenge,            then the card's private key is authenticated and hence the            user is authenticated.

In essence the reader generates (825) an OTP/MAC in the same way as atraditional strong authentication algorithm. All the steps of thisalgorithm (capturing the inputs, formatting the inputs, encrypting orhashing the formatted inputs, transforming the resulting cryptogram ofhash into an OTP/MAC) are done by the reader 800 in essentially the sameway as a traditional strong authentication token. In one embodiment thereader is personalized with a symmetric secret strong authenticationkey. In that case the reader 800 is also typically configured to expecta specific card. The reader recognizes this card by means of somecharacteristic value of a data element of the card. Typically the card'scertificate is used as such a data element. In other embodiments (seeFIG. 9), in order to avoid having to personalize and configure thereaders, the reader 800 derives (835) a card-specific value for thesymmetric secret strong authentication key from the following dataelements:

-   -   public card data preferably related to the card's certificate or        public key (e.g. card serial number, certificate serial number,        public key, etc.)    -   a master key 846 stored in the reader and known to the server.        This master key can be:        -   an identical value for all readers        -   a specific/unique value for each individual reader. This            requires some kind of assignment of the reader to the user,            and registration of this assignment at the server.    -   an (optional) extra derivation data element could be a (secret)        data element that is provided to the reader by the user. The        user must explicitly provide this data element:        -   either, each time the reader and card are used in this way            or,        -   only when this card is used for the first time with this            reader (after which the reader will remember the provided            value of the data element for this card)

The reader 800 uses the derived card-specific symmetric authenticationkey 836 in a symmetric strong authentication algorithm (such as theDigipass algorithm or OATH) to generate (845) a dynamic password(challenge-response and/or time and/or event based) or generate (845) aMAC-type of electronic signature on some transaction data (optionallyincluding time and/or event counter information).

A Server validates the generated dynamic password or signature asfollows:

-   -   The server derives the same card-specific symmetric strong        authentication key as the reader. This assumes that the server        has a database (or an alternative way of retrieving the required        information) that links the user to:        -   the public card data,        -   the data element provided by the user (if applicable)        -   and the reader's master key            -   Note: instead of doing this derivation each time a                validation must be done, the derivation can also be done                once and the resulting derived key can be stored in a                database for future use.    -   The server validates the dynamic password or signature in the        same way as it would do for a traditional strong authentication        token.

A typical embodiment operates as follows (FIGS. 10-11):

In an enlistment phase, a bank customer 1001 goes to a bank branch 1003.Using his national electronic identity card (e-id card 1002) with a BankBranch Terminal (BBT), the customer electronically signs an e-bankingcontract 1004.

While the customer's e-id card is inserted in the BBT (1010), the BBT:

-   -   captures the customer's certificate (1011),    -   generates a random seed challenge (1012),    -   submits the random seed challenge to the e-id card (1002) to be        encrypted by the card's private key (1013),    -   captures the card's cryptogram on that challenge (1014).

Finally, the BBT sends the customer's certificate, generated seedchallenge, and the card's cryptogram on the seed challenge to a server(1015). The server stores this data in a database linked to thecustomer. The bank then delivers an unconnected smart card reader to thecustomer. This reader contains a secret master key. The bank also sendsthe customer a PIN mailer with the value of the seed challenge that wasgenerated and used by the BBT. The authentication server is alsoinformed of the value of the secret master key.

When the customer uses the reader for the first time:

-   -   The reader asks for the customer's e-id card to be inserted.    -   The reader also asks for the PIN mailer's seed challenge and        stores it in memory.    -   The reader reads the card's certificate and stores it also in        memory.    -   The reader generates a random reader challenge and submits it to        the card to be encrypted by the card's private key. The reader        stores both the reader challenge and the corresponding        cryptogram generated by the card.

If the customer wants to generate an OTP (or MAC or response or . . . )the reader goes through the following steps:

-   -   The reader asks for the customer's e-id card to be inserted.    -   The reader validates the card:        -   The reader reads the card's certificate and compares it to            the certificate that was stored.        -   If that checks OK, the reader submits the stored reader            challenge to the card for signature and compares the card's            cryptogram with the stored cryptogram.    -   If the reader has successfully validated the card, the reader        generates the secret authentication key:        -   The reader submits the stored PIN mailer seed challenge to            the card to be encrypted by the card.        -   The reader now derives a secret authentication key from:            -   the secret master key in the reader,            -   the PIN mailer seed challenge,            -   the card's cryptogram on that PIN mailer seed challenge,            -   the card's certificate.    -   The reader now uses the generated secret authentication key in a        strong authentication algorithm (e.g. to generate an OTP or a        MAC).

The authentication server is capable of verifying the resulting OTP (orMAC) since it had access to all the data necessary to generate thesecret authentication key:

-   -   the reader's secret master key,    -   the card's certificate,    -   the PIN mailer challenge,    -   the card's cryptogram on the PIN mailer challenge.

Using the generated secret authentication key, the authentication servercan validate the OTPs or MACs in the same way it would validate OTPs orMACs generated by traditional strong authentication tokens.

Alternatively the authentication server can use either of the proceduresshown in FIG. 13 or 14 for a validation operation.

In connection with the procedure of FIG. 13, we assume that thecryptogram produced by the reader is transformed using a sequence oftransform A (1306) and transform B (1307). For validation purposes theserver subjects the OTP or MAC to the reverse transform B (1327) toproduce a modified OTP or MAC and then subjects the reference cryptogramto transform A (1325) to produce the modified reference cryptogram.Finally the server effects a comparison of the modified referencecryptogram and the modified OTP or MAC.

In connection with the procedure of FIG. 14, we assume that thecryptogram produced by the reader is transformed using a sequence of thebit selection (1355), concatenation (1356) and bit string transformation(1357) as shown in FIG. 14 to produce the OTP or MAC. For validationpurposes the server subjects the OTP or MAC to the bit stream andexpansion processes 1359 and 1360 of FIG. 14 to produce a modified OTPor MAC. The server subjects the reference cryptogram to operation 1364to produce the modified reference cryptogram. Finally the server effectsa comparison (1365) of the modified reference cryptogram and themodified OTP or MAC to effect validation.

FIGS. 15-22 illustrate various aspects of a particular set ofembodiments of the invention. The following devices and data elementsplay a role in these embodiments:

Devices

PKI Device

In the context of this set of embodiments a PKI device 1500 is anapparatus, illustrated in FIG. 15, comprising a memory 1520 for storingat least one private key of a public-private key pair and dataprocessing means 1510 comprising one or more data processing components(such as an Infineon SLE66CLxxx microcontroller) to perform asymmetriccryptographic operations with this private key. The PKI device 1500 mayalso comprise a memory 1525 to store additional private keys and/or oneor more public keys associated to these one or more private keys and/orone or more certificates associated with these one or more public keys.The asymmetric cryptographic calculations typically include thegeneration of digital signatures. The PKI device 1500 may furthermore becapable of other types of cryptographic operations. It may also storeother types of data including user related data such as a user name or aunique number related to the user. In a typical embodiment the PKIdevice 1500 furthermore includes a communication interface 1530 toelectronically communicate and exchange data with certain reader devicesincluding to receive data from such a reader device, to receiveinstructions from the reader device to perform an asymmetriccryptographic operation with an asymmetric private key stored on the PKIdevice on certain data provided by the reader device, and to return aresult of this asymmetric cryptographic operation. In a typicalembodiment this includes digitally signing with a private key certaindata provided by the reader device and returning the resultingsignature. In some embodiments the communication interface 1530 mayinclude a USB interface. In other embodiments the communicationinterface may include a smart card interface. In a typical embodimentthe smart card interface is according to the ISO/IEC 7816 set ofstandards. In some embodiments the PKI device may comprise a USB token.In other embodiments the PKI device may comprise a smart card. In someembodiments the PKI device may be issued by a government agency to atleast some citizens. The PKI device may for instance comprise anelectronic national identity card. In other embodiments the PKI devicemay be issued by financial institutions for example to their customers.In still other embodiments the PKI device may be issued by a companyoffering telecommunication services. In some cases the PKI device maycomprise a SIM (subscriber identity module) card. In some embodimentsoperations involving the usage of the PKI device's private key areprotected by a PIN code. In typical embodiments the private keys storedin the PKI device are only known to the PKI device and cannot be readfrom it. In a particular embodiment the PKI device comprises a PKI smartcard containing at least one public-private key pair with associatedcertificate capable of generating digital signatures with the privatekey whereby the usage of the private key is protected by a PIN code.

Reader Device

In the context of this set of embodiments a reader device 1600 is anapparatus, illustrated in FIG. 16, comprising an electroniccommunication interface 1630 to electronically communicate and exchangedata with certain PKI devices. In a typical embodiment this includesproviding certain data to the PKI device and instructing the PKI deviceto perform an asymmetric cryptographic operation with an asymmetricprivate key stored on the PKI device on the data provided to the PKIdevice and receiving from the PKI device a result of this asymmetriccryptographic operation. In a typical embodiment this may compriseinstructing the PKI device to digitally sign with a private key storedon the PKI device certain data provided by the reader device andreceiving the resulting signature. In some embodiments the readerdevice's electronic communication interface 1630 may include a smartcard reader 1635 to interface with PKI devices comprising a smart card.In a typical embodiment the smart card reader 1635 complies with theISO/IEC 7816 set of standards. The smart card reader's smart cardinterface may also comply with the EMV specifications issued by EMVco(see www.emvco.com). In other embodiments the reader device's electroniccommunication interface 1630 may include a USB interface e.g. tointerface with PKI devices comprising a USB token.

The reader device 1600 furthermore comprises processing means 1620comprising one or more data processing components adapted to performsymmetric cryptographic operations. The data processing components mayfor example comprise a suitably programmed microprocessor, amicrocontroller, an FPGA (Field Programmable Gate Array) or an ASIC(Application Specific Integrated Circuit). The data processingcomponents may for example comprise a Texas Instruments MSP430microcontroller. These symmetric cryptographic operations include thegeneration of a dynamic authentication credential, such as OTPs orelectronic signatures, whereby the reader device's processing means usesa symmetric cryptographic algorithm to combine at least one or moresymmetric secret values with one or more dynamic variables and wherebythe dynamic authentication credential is derived from the result of thatcombination. In a typical embodiment (see FIG. 17) the symmetriccryptographic algorithm 1621 generates dynamic credential(s) (1691) bycombining at least one or more secret keys (1661, 1662, etc.) with oneor more dynamic variables (1671, 1672, etc.) and also with a dataelement (Private Key Related Input Parameter (1681): see below) that isa function of a private key stored in a PKI device. In anotherembodiment the symmetric cryptographic algorithm generates dynamiccredential(s) by combining one or more dynamic variables with asymmetric secret value that is or is derived from the Private KeyRelated Input Parameter. In some embodiments the symmetric cryptographicalgorithm generating dynamic credentials may comprise a symmetricencryption or decryption algorithm such as DES or AES. In a typicalembodiment the generation of a dynamic authentication credentialcomprises the encryption or decryption, with a secret symmetric key,using a symmetric encryption or decryption algorithm, of a combinationof at least one or more dynamic variables with a Private Key RelatedInput Parameter. In some other embodiments the symmetric cryptographicalgorithm may comprise a keyed-hash algorithm. In a typical embodimentthe generation of a dynamic authentication credential comprises hashinga combination of a secret value, a dynamic value and a Private KeyRelated Input Parameter. The dynamic variable may include a time relatedvalue, a counter value, a challenge provided by some application,transaction related data, or a combination of the aforementioned. In aspecific embodiment the symmetric cryptographic algorithm comprises aknown or standardized symmetric algorithm to generate OTPs or electronicsignatures that combines a symmetric secret with a first externaldynamic variable and a second internal or external dynamic variable andwhereby the reader device assigns the value of a Private Key RelatedInput Parameter to the first external dynamic variable. The known orstandardized symmetric algorithm to generate OTPs or electronicsignatures may include an OATH or DIGIPASS challenge-response ortransaction data signing algorithm.

The reader device 1600 may comprise a real-time clock 1650 to provide atime-related value. It may also comprise a memory 1610 to store acounter value. It may furthermore comprise a memory 1610 to store one ormore secret keys or secret values. It may also comprise one or moreother memory components 1610 to store data such as a PKI device specificor private key specific challenge, or data related to a PKI device or aprivate key on the PKI device that permits the reader device later on torecognize that PKI device or that private key on the PKI device.

The reader device 1600 furthermore comprises one or more outputcomponents 1660 to output at least the dynamic authenticationcredential(s). In a typical embodiment the reader device may also usethe output components to output a Private Key Code (see further). Insome embodiments the output components 1660 comprise a display.Different types of displays can be used. The display may comprise forexample a CRT (Cathode Ray Tube), LED (Light Emitting Diode), or LCD(Liquid Crystal Display) display. The output components may alsocomprise a display or LCD controller. In other embodiments the outputcomponents 1660 generate an output in acoustical form, such as anelectromagnetic speaker. In other particular embodiments these outputcomponents are adapted to generate and output synthesized voice.

In some embodiments the reader device 1600 may furthermore compriseinput components 1670 to receive data such as external dynamic variablevalues (e.g. a challenge or transaction data), or a PIN value e.g. to besubmitted to a PKI device, or an Activation Code. In some embodimentsthe input components may comprise a keyboard or a keypad. In otherembodiments the input components may comprise an optical interfacecomprising a plurality of light sensors.

In a typical embodiment the reader device has an autonomous power supplysuch as one or more batteries. In some embodiments these batteries maybe replaceable.

Server-Side Components

The reader device described above is typically used by a user inconjunction with a user's PKI device for generating dynamic credentialsto secure some computer-hosted application. In a typical embodiment thecomputer-hosted application interfaces with or comprises one or moreauthentication components for verifying dynamic credentials receivedfrom the application's users. Other server-side components may compriseone or more databases to store data linked to specific users such as areader device identifying data element of a reader device associatedwith a specific user or the value of a Private Key Related InputParameter associated with a specific user, and/or data linked tospecific reader devices such a one or more secret keys.

Application Server

The computer-hosted application is typically hosted by an applicationserver which the user can access via a network. In a typical case theapplication is web-based, the application server is a web server, thenetwork is the internet, and the user can access the application bymeans of a browser on a web-enabled client device. In other embodimentsthe application may have an IVR (Interactive Voice Response) interfaceand the user may access the application via a telephone network. Instill other embodiments the application is present on a local computerdevice that is directly accessed by a user. In all these cases,including the latter case we will refer to the application and itsassociated components as the server-side and server-side components.

Authentication Software/Server/Appliance

One or more of the authentication components may comprise anauthentication software library that is integrated into applicationsoftware and that offers dynamic credential verification functionalityto the application. In other embodiments one or more authenticationcomponents may comprise a stand-alone authentication server using someauthentication protocol for verifying received dynamic credential(s). Insome embodiments one or more authentication components may comprise anauthentication appliance. In a typical embodiment, as illustrated inFIG. 18, two levels or layers can be distinguished in the one or moreauthentication components.

A first (inner or core) layer 1801 comprises one or more components forverifying dynamic credential(s) using an existing or standardizeddynamic credential verification algorithm that cryptographicallycombines at least one symmetric secret key with at least a firstexternal dynamic variable (such as a challenge or transaction relateddata) and a second internal or external dynamic variable (e.g. a counteror a time dependent variable). In some embodiments additional externalor internal dynamic variables may also be used by the verificationalgorithm. The interface of this inner or core layer contains at least afunction or functionality for verifying dynamic credentials whereby thecalling component is expected to pass the dynamic credential and atleast the value of the first external dynamic variable and, ifapplicable, also the values of the additional external variables. Insome embodiments the symmetric secret key is also passed by the callingcomponent through the interface. In other embodiments the callingcomponent passes a data element related to the user identity or a readeridentifier and the inner layer comprises one or more components todetermine the value of the symmetric secret key using the received dataelement related to the user identity or a reader identifier. Thisdetermining of the value of the symmetric key may include a databasesearch using the received data element related to the user identity or areader identifier as a search key.

A second (outer layer) 1802 includes an interface that includes afunction or functionality for verifying a dynamic authenticationcredential that has been generated by a reader device (1600) asdescribed above in connection to the description of a reader device(FIG. 16). The interface of the outer layer allows a calling applicationto pass a dynamic authentication credential to be verified along with avalue that is related to the identity of the user that is supposed tohave submitted the dynamic credential or an identifier of the readerthat is supposed to have generated the dynamic credential and mayoptionally also allow to pass one or more external dynamic variablessuch as a challenge or transaction data. The outer layer comprises oneor more components that, using the received user identity related valueor reader identifier, determines or retrieves the value of a Private KeyRelated Input Parameter. Determining or retrieving the value of aPrivate Key Related Input Parameter may comprise doing a database searchusing the received user identity related value or reader identifier (ordata related to it) as a search key. For the verification of thereceived dynamic credential the outer layer calls upon the inner layerpassing it the received dynamic credential to be verified along with theobtained value of the Private Key Related Input Parameter which isassigned to the first external dynamic variable that the inner layerexpects. If applicable the outer layer also passes the values ofadditional external dynamic variables (e.g. a challenge or transactiondata) to the inner layer. In some embodiments, i.e. in cases the innerlayer expects that the value of the symmetric secret key is passedthrough the interface, the outer layer comprises one or more componentsto determine the value of the symmetric secret key using the dataelement related to the user identity or a reader identifier that itreceived from the calling application. This determining of the value ofthe symmetric key may include a database search using the received dataelement related to the user identity or a reader identifier as a searchkey. In other embodiments the outer layer passes to the inner layer adata element related to the user identity or a reader identifier thatthe inner layer can use to determine the value of the symmetric secretkey(s).

In some embodiments the dynamic credentials may have been generatedusing a User Identity Code (see below for details) in addition to theother data elements (symmetric reader key, PKRIP, dynamic variables).For verification of the received dynamic credentials the authenticationcomponents of the server-side also determine a User Identity Code valueand then used in the verification calculations. In one embodiment theouter layer determines the User Identity Code and passes it to the innerlayer as the value of an external dynamic variable that the inner layerexpects (similarly to what is described above with respect to thePrivate Key Related Input Parameter).

In this way an embodiment of the invention can be produced by using, asthe inner core, one or more existing components for verifying a dynamiccredential which have not been designed to implement an embodiment ofthe invention disclosed herein, and adding only the outer layercomprising one or more components in accordance with embodiments of theinvention disclosed herein.

Data Elements

User ID

In one set of typical embodiments users interact with an application orcomputer system and identify themselves to the application or computersystem by means of User ID. In a preferred embodiment this User IDcomprises a code that uniquely identifies each individual user. In somecases the User ID may comprise a name associated with the user. In othercases the User ID may comprise an account number. In some cases the UserID may comprise a number while in other case it might comprise analphanumerical string. In some embodiments the User ID may be chosen bythe application provider whereas in other embodiments the User ID may bechosen by the user.

Private Key Code and Private Key Related Input Parameter

The Private Key Related Input Parameter (PKRIP) is a data element thatis used by the reader device 1600 to generate dynamic authenticationcredentials and that is used by the server-side to verify authenticationcredentials generated by the reader device. The Private Key Code is adata element that is originally generated at registration and enablementby the reader device 1600 and transported to the server-side and fromwhich the server-side can calculate the PKRIP. The Private Key Code andthe PKRIP are both a mathematical function of the user's private keyfrom the user's PKI device. The reader 1600 mathematically derives thePKRIP from a cryptogram that is generated by the user's PKI device 1500using the user's private key with an asymmetric cryptographic operationin response to a challenge (further also referred to as the PKRIPchallenge) from the reader device. For example the PKRIP may bemathematically derived from the result of an asymmetric cryptographicoperation, such as decryption or a signature, by the user's PKI deviceusing the user's private key and an asymmetric cryptographic algorithmin response to a challenge from the reader device 1600. In someembodiments the deriving may include a hashing and/or truncationoperation. In other embodiments the deriving may also includecryptographically combining a secret with data mathematically related tothe private key or specifically the result of a decryption or asignature by the user's PKI device using the user's private key with anasymmetric cryptographic operation in response to a challenge from thereader device. In still other embodiments the deriving may also includecombining other types of data with data mathematically related to theprivate key or more specifically to the result of a decryption or asignature by the user's PKI device using the user's private key with anasymmetric cryptographic operation in response to a challenge from thereader device. In some embodiments these other types of data may includedata specific for the reader device such as a reader device serialnumber, or data specific for the user such as the user's name or a useridentifier which in some embodiments may be provided by the user to thereader device, or data specific to the PKI device such as a serialnumber, or data specific for the private key such as data from orrelated to the public key or a certificate associated with the privatekey, or data specific to an application provider which in someembodiments may be provided by the user to the reader device. Thealgorithm to derive the PKRIP could make use of the following extra dataelements:

-   -   1. A fixed value that is the same for all reader devices of a        certain batch.    -   2. A fixed value that is fixed for a given reader device but        that has a different value for each reader device.    -   3. A fixed value that is constant for a given user but that can        be different for different users and that is entered at least        once in the reader device by the user.    -   4. Static data stored on the PKI device that can be read by the        reader device (e.g. data associated with the private key such as        the public key and certificate, or a serial number of the PKI        device).    -   5. A combination of any of the above.

In typical embodiments the PKRIP challenge is a value that is determinedor calculated by the reader device in a way that the reader device canre-determine or re-calculate the same value of the PKRIP challenge lateron for the same PKI device or the same private key on the PKI device. Ina typical embodiment the PKRIP challenge comprises a secret or anunpredictable value. In some embodiments the PKRIP challenge is aconstant or is derived from a constant that is stored in the readerdevice. In a specific embodiment this constant is the same for aplurality of reader devices. In another specific embodiment thisconstant is specific to an individual reader device. In some typicalembodiments this constant is a secret. In other embodiments the PKRIPchallenge is or is derived from a random or pseudo-random value. In someembodiments after generation of the PKRIP challenge the reader devicestores in persistent memory for later use a value that permits tore-determine or re-calculate the PKRIP challenge. In one embodiment thisstored value may be the PKRIP challenge itself. In some embodiments thisvalue is stored together with information that is related to the PKIdevice or the user's private key on the PKI device that permits thereader device to recognize the PKI device or the private key on the PKIdevice. This information may comprise a serial number of the PKI deviceor data from or related to the private key on the PKI device. In someembodiments, the PKRIP challenge could for example comprise or could bederived from any of the following:

-   -   1. A fixed value that is the same for all reader devices of a        certain batch.    -   2. A fixed value that is fixed for a given reader device but        that has a different value for each reader device.    -   3. A fixed value that is constant for a given user but that can        be different for different users and that is entered at least        once in the reader device by the user. In practice it is very        likely that this value will be entered either every time the PKI        device is used, or only the first time that a given PKI device        is used with a certain reader device and will then be remembered        by the reader device.    -   4. Static data stored on the PKI device that can be read by the        reader device (e.g. the public key and certificate, or a PKI        device serial number).    -   5. Data specific to a particular application provider which in        some embodiments may be provided by the user to the reader        device.    -   6. A combination of any of the above.    -   7. A value derived from any of the above. The derivation        optionally including the use of some reader device secret.

The Private Key Code is generated by the reader device and ismathematically related to the PKRIP. In a typical embodiment the PrivateKey Code is generated such that the server-side can calculate the valueof the PKRIP from the Private Key Code value. In some embodiments theserver-side also uses additional data elements that it has access to tocalculate the PKRIP from the Private Key Code value. In some embodimentsthese additional data elements may include secret data also known to thereader device, or data related to the user that are accessible to theserver-side such as a user name or a User ID, or data related to thereader device and accessible to the server-side such as a reader deviceserial number (which in some embodiments may be provided to theserver-side by the user at registration), or data related to the PKIdevice such as a serial number, or data related to the private keystored on the PKI device which is accessible to the server-side (in someembodiments this may include data from or related to the public key or acertificate associated with the private key and which the server-sidecan access e.g. in a database). In some embodiments the Private Key Codeis an intermediate data element that the reader device generates whengenerating the PKRIP. In other embodiments the reader devicemathematically derives the Private Key Code from the PKRIP after it hasgenerated the PKRIP. In a particular embodiment the Private Key Code isthe same as the PKRIP. In a typical embodiment the Private Key Code isgenerated by the reader and transported at registration to theserver-side to allow the server-side to calculate or otherwise obtainthe value of the PKRIP that the reader device has calculated.

Activation Key and Activation Code

The Activation Key is a symmetric secret key that is used in someembodiments when registering and enabling a user's PKI device or morespecifically the private key stored in that PKI device that is used togenerate the PKRIP. In a typical embodiment the Activation Key is usedat registration for securing the transport to the server side of thePrivate Key Code generated by the reader device. In one embodiment theActivation Key is known to or calculated by the reader device atregistration. In one embodiment the Activation Key is used by the readerdevice to encrypt the Private Key Code which is then in encrypted formtransported from the reader device to the server-side. In one embodimentthe Activation Key is also known to or calculated by the server-side atregistration. In one embodiment the server-side receives the encryptedPrivate Key Code and decrypts the encrypted Private Key Code with itscopy of the Activation Key.

In some embodiments the Activation Key is derived from a symmetricsecret known to both the reader device and the server-side. In oneembodiment the Activation Key is a symmetric secret known to both thereader device and the server-side. In another particular embodiment theActivation Key is derived from a cryptographic combination of a dynamicvariable such as a time-related variable or a challenge with a symmetricsecret.

In some embodiments the Activation Key is derived from a symmetricsecret that is already present in the reader device before the readerdevice is distributed to the user. In one embodiment the Activation Keyis a symmetric secret that is already present in the reader devicebefore the reader device is distributed to the user. In a specificembodiment the Activation Key is loaded in the reader device as part ofa production step and communicated to the server-side prior toregistration of the user's PKI device or more specifically the privatekey stored in that PKI device that is used to generate the PKRIP.

In some embodiments the Activation Key is derived from a data elementwhich is generated at the server side and after generation provided tothe reader device. This data element is further referred to as theActivation Code. In a typical embodiment the Activation Code is providedto the reader device by the user. In some embodiments the user may enterthe Activation Code on the keyboard of the reader device. In someembodiments the user receives the Activation Code via a delivery channelthat is deemed to provide a sufficiently high level of security. In oneembodiment the Activation Code is delivered to the user when the userhas logged in using an older authentication technology (e.g. using astatic password). In another embodiment the Activation Code is sent bymail (e.g. registered mail) to the user. In yet another embodiment theuser can get the Activation Code via an ATM (automatic teller machine)machine e.g. after having inserted a bank card and having entered thePIN associated with that bank card. In still another embodiment theActivation Code is sent via a text message or SMS (short messageservice) message to a mobile phone that is deemed to be under control ofthe user. In still another embodiment the Activation Code is sent viae-mail to an e-mail account that is deemed to be under control of theuser.

In some embodiments the derivation of the Activation Key uses dataelements that are specific for the reader device such as a reader deviceserial number, or data elements that are specific for the user such asthe user's name or a user identifier which in some embodiments may beprovided by the user to the reader device.

User Identity Code

In some embodiments the User Identity Code is a data element that thereader device can derive from a data element that is stored on the PKIdevice and that can be accessed by the reader device and that isrepresentative for or linked to the identity of the legitimate holder ofthe PKI device, and that is also accessible to the server-side e.g. byaccessing a public database if the identity of the legitimate holder ofthe PKI device is given. Examples of such data elements may include thePKI device holder's name, or PKI device holder's address, or (forexample in case the PKI device comprises a national ID card) a PKIdevice holder's national number which may be unique for each PKI deviceholder, or (e.g. in case the PKI device has been issued by a financialinstitution) a PKI device holder's account number. In some embodimentsthis data element may be comprised in a certificate associated with thePKI device holder's private key on the PKI device. In some otherembodiments the server-side may have access to a database containingcertificates or public keys associated with private keys of users. Thedata element from which the User Identity Code is derived may thencomprise parts of a certificate or public key associated with a user'sprivate key on the PKI device. The User Identity Code may allow theserver to perform a check on whether the identity that the user claimscorresponds to the identity of the legitimate holder of the PKI devicethat the user is using.

In one embodiment the User Identity Code is derived by the reader deviceduring the registration phase from a data element on the PKI device thatthe user is using, and is then communicated to the server side. Toverify that the identity that the user claims corresponds to theidentity of the legitimate holder of the PKI device that the userhappens to use, the server side may generate a similar value from a dataelement that corresponds to the data element on the PKI device, that isaccessible to the server-side and that the server-side can retrieve onthe basis of the identity that the user claims. The server side may thencompare the received User Identity Code with the value that it computeditself. If the identity claimed by the user indeed corresponds to theidentity of the legitimate holder of the PKI device that the userhappens to use, then this comparison should give a positive result.

In another embodiment the User Identity Code is derived by the readerdevice when it generates dynamic credentials and cryptographicallycombined with other data elements (symmetric reader secret, PKRIP,dynamic variables) to generate the dynamic credentials. When verifying adynamic credential the server-side determines the value of the UserIdentity Code on the basis of the identity that the user claims to have.If the user claims to have an identity that is different than theidentity of the legitimate holder of the PKI device that the user isusing, then the User Identity Code derived by the reader device and theUser Identity Code determined by the server-side will be different andthe verification by the server side of the dynamic credential can beexpected to produce a negative result. This provides an implicit methodfor the server side to verify that the identity that the user claimscorresponds to the identity of the legitimate holder of the PKI devicethat the user happens to use.

Methods

Securing an Application

In some embodiments a method, illustrated in FIG. 19, for securing auser's accessing and/or interacting with a computer-based applicationmay comprise the following steps:

-   -   Ensuring for a plurality of users that each user has access to a        PKI device linked to that user (1905); said PKI device storing a        private key and adapted to perform asymmetric cryptographic        operations with that private key and having a communication        interface to electronically communicate and exchange data with        compatible reader devices including to receive data from such a        reader device, to receive instructions from the reader device to        perform an asymmetric cryptographic operation with an asymmetric        private key stored on the PKI device on certain data provided by        the reader device, and to return a result of this asymmetric        cryptographic operation. In some embodiments the PKI device may        comprise a smart card or a USB token. In some embodiments this        step may be optional or implicit e.g. in cases where users can        by default be assumed to have a usable PKI device. This may for        instance be the case in a country where all citizens receive a        national ID card that is PKI enabled. In other embodiments e.g.        in the case of a financial institution issuing PKI devices this        step may comprise ensuring that for each user a public-private        key pair is generated and stored on a PKI device, that the        public key of that key pair is certified and linked to the        appropriate user, that the PKI device is provided to the        appropriate user, and (optionally) that a PIN mailer is sent to        the appropriate user.    -   Ensuring for a plurality of users that each user gets a reader        device as described above (1908); said reader device being        suitable to handle Activation Keys and Activation Codes and to        generate Private Key Codes, Private Key Related Input Parameters        and dynamic authentication credentials as described above and        below.    -   Registering (1910) for each of a plurality of users the private        key on a PKI device associated with each user (see below for a        description of the registration step)    -   Receiving (1915) from a plurality of users dynamic credentials        that have been generated by these users using their PKI device        and reader device (see below for a description of the generation        of the dynamic credentials)    -   Verifying (1925) the received dynamic credentials (see below for        a description of the verification of the dynamic credentials)    -   Taking appropriate action depending on the outcome of the        verification step. For example in some embodiments users may        gain access to an application after successful verification of        an OTP (1935) and may be refused access in case the verification        of the OTP was unsuccessful (1945). In other embodiments        instructions or transactions received by a user may be performed        after successful verification of an OTP or an electronic        signature on the instruction or transaction data and may be        refused in case the verification of the OTP or electronic        signature was unsuccessful.

In some embodiments the application to be secured comprises a financialapplication such as an internet-banking application. In otherembodiments the application to be secured comprises an e-government suchas electronically submitting a tax-declaration. In still otherembodiments the application to be secured comprises a social security orhealth-care related application such as interacting with a medicalinsurance. In yet other embodiments the application to be securedcomprises a lottery application.

Registration/Enablement of a Private Key

As illustrated in FIGS. 20A and 20B, the step of registering a user'sprivate key on a user's PKI device comprises in a typical embodiment thefollowing steps:

-   -   In some embodiments an Activation Code is provided to the user        (2005).    -   The user takes his/her reader device and PKI device and let's        them perform the following steps.    -   The reader device obtains a PKRIP and Private Key Code, which in        turn comprises the steps of:        -   i. Generating a PKRIP challenge as described above (2006).        -   ii. Sending the PKRIP challenge to the PKI device and            instructing the PKI device to perform an asymmetric            cryptographic operation on that PKRIP challenge with a            private key stored in the PKI device and receiving from the            PKI device the result of that operation (2009).        -   iii. Deriving from the result of that operation a first            value called Private Key Code and (optionally) a second            value called PKRIP (2010).    -   The reader device obtains an Activation Key and encrypts the        generated

Private Key Code with the obtained Activation Key (2011). In someembodiments the reader device first obtains an Activation Code andderives the Activation Key from the obtained Activation Key. In atypical embodiment the user provides the Activation Code to the readerdevice (e.g. by entering it on the reader device's keypad). In anothertypical embodiment the Activation Code is a representation of theActivation Key.

-   -   In some embodiments the reader device also obtains a data        element from the PKI device that is linked to the user's        identity and which can also be obtained by the server-side, and        generates from that data element a User Identity Code.    -   In some embodiments the reader device also generates a dynamic        credential using the PKRIP.    -   The encrypted Private Key Code, and if applicable also the User        Identity Code and/or the generated dynamic credential, are        communicated to the server-side (2014). In some embodiments also        a value that allows the server-side to identify the user's        reader device (such as a reader device's serial number) is        communicated to the server-side. In a typical embodiment        communication of these data elements from the reader device to        the server-side is done by the user e.g. by reading these data        elements from the reader device's display and copying them on a        web-page of the server-side.    -   The server-side receives the encrypted Private Key Code and if        applicable the User Identity Code and/or the generated dynamic        credential and/or a reader device identifying data element        (2016).    -   The server-side also obtains a copy of the Activation Key. In        some embodiments the server-side obtains a copy of an Activation        Code that has been provided to the user and derives the        Activation Key from that copy of the Activation Code. In some        other embodiments the server-side obtains from a database a        value from which the Activation Key can be derived. In some        embodiments the server-side obtains from a database the value of        the Activation Key itself.    -   The server-side decrypts the received encrypted Private Key Code        (2018).    -   The server-side derives from the Private Key Code a value that        permits the server-side to calculate the corresponding PKRIP        (2019) and stores that value linked to the user e.g. in a        database (2020). In some embodiments this value may be the        Private Key Code. In other embodiments this value may be the        PKRIP itself.    -   If applicable the server-side uses the reader device identifying        element to retrieve reader device specific data elements (such        as a reader device specific configuration parameter or secret        key) used in the calculation or verification by the server-side        of data elements generated by the reader device. These data        elements generated by the reader device that are also calculated        or verified by the server-side may include the Activation Key,        the PKRIP, the User Identity Code, and/or any dynamic credential        (such as an OTP or electronic signature) generated by the reader        device. If applicable the server-side may store the reader        device identifying element linked to the user for later use. In        a typical embodiment the reader device uses one or more reader        device specific secrets in the generation of dynamic credentials        and the server-side stores the reader device identifying element        in a database linked to the user and uses that stored reader        device identifying element to retrieve the one or more reader        device specific secrets from another database (which stores        these one or more reader device specific secrets linked to the        reader device identifying element) when verifying dynamic        credentials provided by the user.    -   If applicable the server-side may derive its own copy of the        User Identity Code and compare it to the received User Identity        Code. In some embodiments the registration fails or is refused        if this comparison fails.    -   If applicable the server-side may verify the received dynamic        credential. In some embodiments the registration fails or is        refused if this verification fails.

Generation of Dynamic Credentials

In a typical embodiment a reader device generates dynamic credentials(2120) according to a method, illustrated in FIG. 21, that comprises thefollowing steps:

-   -   The reader device obtains a PKRIP (2110).    -   The reader device cryptographically combines this PKRIP with one        or more dynamic variables using a symmetric cryptographic        algorithm (2115).    -   In some embodiments the combining also involves one or more        symmetric reader secrets.    -   In some embodiments the combining also involves a User Identity        Code.

In some embodiments obtaining the PKRIP comprises generating a PKRIPchallenge, sending this PKRIP challenge to a PKI device, instructing thePKI device to perform an asymmetric cryptographic operation on the PKRIPchallenge using a private key stored on the PKI device, receiving fromthe PKI device the result of that asymmetric operation, andmathematically deriving the PKRIP from the received result of theasymmetric operation. In some embodiments said asymmetric operationcomprises the generation of a digital signature with a private keystored on the PKI device and said result of the asymmetric operationcomprises the resulting digital signature. In some embodiments derivingthe PKRIP from the received result of the asymmetric operation comprisescombining the result of the asymmetric operation with data stored in thereader device. In some embodiments these data stored in the readerdevice may comprise data specific to an individual reader device. Inother embodiments these data stored in the reader device may compriseone or more secret values or keys.

In some embodiments cryptographically combining the PKRIP with one ormore dynamic variables using a symmetric cryptographic algorithmcomprises combining the PKRIP and one or more dynamic variables with oneor more secret values stored in the reader device using a symmetriccryptographic algorithm. In some embodiments these one or more secretvalues comprise a secret value that is common to a plurality of readerdevices. In some other embodiments these one or more secret valuescomprise a secret value that is specific for an individual readerdevice.

In some embodiments the reader device may derive a User Identity Code asdescribed above and cryptographically combining the PKRIP with one ormore dynamic variables using a symmetric cryptographic algorithmcomprises combining the PKRIP and one or more dynamic variables and thederived User Identity Code. In some embodiments cryptographicallycombining the PKRIP with one or more dynamic variables using a symmetriccryptographic algorithm comprises combining the PKRIP and one or moredynamic variables and the derived User Identity Code with one or moresecret values stored in the reader device using a symmetriccryptographic algorithm.

In a specific embodiment cryptographically combining the PKRIP with oneor more dynamic variables using a symmetric cryptographic algorithmcomprises applying to the PKRIP, the one or more dynamic variables and asymmetric secret value stored in the reader device, a known orstandardized symmetric algorithm to generate OTPs or electronicsignatures that combines a symmetric secret with a first externaldynamic variable and at least a second internal or external dynamicvariable and whereby the reader device assigns the value of a PrivateKey Related Input Parameter to the first external dynamic variable andthe symmetric secret value stored in the reader device to the symmetricsecret and one of the one or more dynamic variables to the at least asecond internal or external dynamic variable.

Verification of Dynamic Credentials

In a typical embodiment a dynamic credential that has been received isverified (2220) at the server-side according to a method, illustrated inFIG. 22, that comprises the following steps:

-   -   The server-side obtains a PKRIP (2205).    -   The server-side cryptographically combines this PKRIP with one        or more dynamic variables using a symmetric cryptographic        algorithm to obtain a reference value (2210).    -   The server-side compares this reference value with the received        dynamic credential (2215).

In some embodiments obtaining the PKRIP comprises retrieving from adatabase a data element that is linked to the user and which permits theserver-side to calculate the corresponding PKRIP. In some embodimentsthis value may be the Private Key Code. In other embodiments this valuemay be the PKRIP itself. In some embodiments the server-side combinesthis data element with other data elements. In some embodiments theseother data elements may comprise data elements that may be linked to thereader or to the user to calculate the PKRIP. In some embodiments theseother data elements may comprise one or more secret keys.

In some embodiments cryptographically combining the PKRIP with one ormore dynamic variables using a symmetric cryptographic algorithmcomprises combining the PKRIP and one or more dynamic variables withserver-side copies of one or more secret values stored in a readerdevice using a symmetric cryptographic algorithm. In some embodimentsthese one or more secret values comprise a secret value that is commonto a plurality of reader devices. In some other embodiments these one ormore secret values comprise a secret value that is specific for anindividual reader device. In some embodiments the server-side retrievesthese one or more secret values from a database that stores these valueslinked to a user identifying data element or linked to a reader deviceidentifying data element.

In a specific embodiment cryptographically combining the PKRIP with oneor more dynamic variables using a symmetric cryptographic algorithmcomprises applying to the PKRIP, the one or more dynamic variables and aserver-side copy of a symmetric secret value stored in a reader device,a known or standardized symmetric algorithm to generate OTPs orelectronic signatures that combines a symmetric secret with a firstexternal dynamic variable and at least a second internal or externaldynamic variable and whereby the server-side assigns the value of aPrivate Key Related Input Parameter to the first external dynamicvariable and the symmetric secret value stored in the reader device tothe symmetric secret and one of the one or more dynamic variables to theat least a second internal or external dynamic variable.

In a particular embodiment reader devices are being made available to aplurality of users. The reader devices may be distributed by anapplication provider to some of its users e.g. by mail. The readerdevices may also be for sale in e.g. a supermarket or on web shop. Thereader devices are adapted to interact with a PKI device e.g. a smartcard that is issued by a government agency to citizens to act aselectronic id card for those citizens and that contains a private keyand associated certificates and that is capable of asymmetriccryptographic operations with the private key e.g. to generate a digitalsignatures or to decrypt data encrypted with the public key associatedwith the private key. All readers contain a certain challenge which isthe same for all readers. All reader devices also contain a symmetricreader secret which is the same for all reader devices. The applicationprovider provides the users also with a personal Activation Code in asecure way e.g. by sending them using registered mail. The ActivationCodes may consist of a sequence of decimal digits. The value of eachActivation Code is secret and personalized for each user. The ActivationCodes are determined such that it is difficult for an outsider topredict the values. They may for example be random numbers or by derivedby cryptographically combining a secret key with a User ID. To detecttypographic errors the Activation Code may have a check digit. Theapplication provider keeps track which user has received whichActivation Code

The application provider invites the users to register themselves. Toregister, a user logs in and authenticates using an existingauthentication mechanism e.g. using a static password in combinationwith his/her User ID. The user then inserts his or her PKI device (e.g.their electronic ID card) into his or her reader device and enters hisor her Activation Code on the reader device. The reader device requeststhe user to insert his/her PKI device and to enter the PKI devices PIN.The reader device submits the PIN to the PKI device for verification.The reader device then instructs the PKI device to digitally sign theabove mentioned challenge with the user's private key stored in theuser's PKI device. The reader device receives the resulting digitalsignature and derives a PKRIP from that digital signature e.g. it maytake the first 5 bytes of the asymmetric cryptogram that is present inthe digital signature and convert these 5 bytes into its decimalrepresentation. The reader then encrypts the PKRIP by doing a modulo-10addition of each PKRIP digit with the corresponding digit in theActivation Code that was entered by the user. The reader displays thethus encrypted PKRIP on its display and the user communicates thedisplayed encrypted PKRIP to the registration application (e.g. bycopying the encrypted PKRIP onto a webpage of the registrationapplication in the user's web browser). The application providerretrieves the Activation Code that was provided to that particular userand uses it to decrypt the received encrypted PKRIP using. Theapplication provider then stores the PKRIP (e.g. in a database) linkedto the user's User ID.

From now on when the user wants to access the application provider'sapplication, the user is requested to log in by providing his/her UserID and an OTP generated by his/her reader device in conjunction withhis/her PKI device. The reader device generates OTPs as follows. Thereader device requests the user to insert his/her PKI device and toenter the PKI devices PIN. The reader device submits the PIN to the PKIdevice for verification. Then the reader device submits the abovementioned challenge to the PKI device and instructs the PKI device todigitally sign the challenge with the user's private key stored on thePKI device. The reader device receives the resulting digital signatureand derives the same PKRIP from that digital signature as the PKRIP thatwas derived for the registration phase. The reader generates an OTP bycryptographically combining the PKRIP with a dynamic variable (such asthe value of the reader device's real-time clock or a counter maintainedby the reader device) and the above mentioned symmetric reader secretusing a symmetric cryptographic algorithm. The reader device may forexample concatenate the PKRIP and the dynamic variable and encrypt theconcatenation with the AES encryption algorithm using the symmetricreader secret as the AES encryption key, after which the reader maydecimalize a part (e.g. the first 3 bytes) of the resulting cryptogramand display the result as the OTP on its display for the user tocommunicate to the application. In one embodiment, the reader device mayfeed the PKRIP value to an OTP generation algorithm which takes at leasttwo dynamic variables at least one of which is originally conceived tobe an external dynamic variable (such as a challenge) and to which thereader device assigns the PKRIP values. For example the reader devicemay use an OTP algorithm that uses two dynamic variables: a firstinternal time-based dynamic variable and a second external dynamicvariable that is originally conceived to be assigned a challenge valuegenerated by the application, whereby the reader device assigns thePKRIP value to the second dynamic variable.

The authentication component of the application verifies the receivedOTP as follows. Using the User ID as a search key it retrieves the PKRIPvalue associated with the user. It determines the value of the symmetricreader secret. It determines the values of the dynamic variable used inthe generation of the received OTP. It then cryptographically combinesthe retrieved PKRIP value and the determined value for the dynamicvariable with the determined symmetric reader secret using a symmetriccryptographic algorithm that is similar to the algorithm used by thereader devices. The result of this cryptographic combining is thencompared to the received OTP. The authentication component may forexample concatenate the retrieved PKRIP value and the determined valuefor the dynamic variable and encrypt the concatenation with the AESencryption algorithm using the symmetric reader secret as the AESencryption key, after which it may decimalize a part (e.g. the first 3bytes) of the resulting cryptogram and check whether the result is thesame as the received OTP. In one embodiment the authentication componentcomprises two layers. A first layer is an inner layer that is capable ofverifying an OTP generated using a symmetric secret, a first dynamicvariable and a second dynamic variable that is originally conceived tobe an external dynamic variable e.g. a challenge. The inner layer has aninterface that expects the OTP to be verified, the secret key and thevalue of the external dynamic variable. The second layer is an outerlayer which is called by the application to verify the received OTP. Theouter layer contains the symmetric reader secret and determines theuser's PKRIP value on the basis of the User ID received from the callingapplication. To verify the OTP the outer layer calls the inner layer andpasses the OTP and the symmetric reader secret and it passes the PKRIPvalue as the value for the second external dynamic variable. The innerlayer verifies the OTP and returns the result to the outer layer whichreturns the result to the application.

One advantage of this embodiment is that the user can use any readerdevice and can even change at any moment from one reader device toanother.

In another particular embodiment reader devices are being made availableto a plurality of users. The reader devices may be distributed by anapplication provider to some of its users e.g. by mail. The readerdevices may also be for sale in e.g. a supermarket or on web shop. Thereader devices are adapted to interact with a PKI device e.g. a smartcard that is issued by a government agency to citizens to act aselectronic id card for those citizens and that contains a private keyand associated certificates and that is capable of asymmetriccryptographic operations with the private key e.g. to generate a digitalsignatures or to decrypt data encrypted with the public key associatedwith the private key. All reader devices contain a certain challengewhich is unique for each reader device. All reader devices also containa symmetric reader secret which is unique for each reader device. Allreader devices have furthermore a secret Activation Key that is uniquefor each reader device.

The application provider invites the users to register themselves. Toregister, a user logs in and authenticates using an existingauthentication mechanism e.g. using a static password in combinationwith his/her User ID. The user then inserts his or her PKI device (e.g.their electronic ID card) into his or her reader device and enters hisor her Activation Code on the reader device. The reader device requeststhe user to insert his/her PKI device and to enter the PKI devices PIN.The reader device submits the PIN to the PKI device for verification.The reader device then instructs the PKI device to digitally sign itsreader device specific challenge with the user's private key stored inthe user's PKI device. The reader device receives the resulting digitalsignature and derives a PKRIP from that digital signature e.g. it maytake the first 5 bytes of the asymmetric cryptogram that is present inthe digital signature and convert these 5 bytes into its decimalrepresentation. The reader then encrypts the PKRIP by doing a modulo-10addition of each PKRIP digit with the corresponding digit in the readerdevice's Activation Key. The reader displays the thus encrypted PKRIP onits display and the user communicates the displayed encrypted PKRIP tothe registration application (e.g. by copying the encrypted PKRIP onto awebpage of the registration application in the user's web browser). Theuser also communicates the serial number of the reader device he or sheis using to the application.

The application provider has a database that lists the reader devicespecific symmetric reader secrets and Authentication Keys linked to theserial number of the corresponding reader device. The applicationretrieves the Activation Key of the reader device that the user uses anduses that Activation Key to decrypt the received encrypted PKRIP using.The application provider then stores (e.g. in a database) the PKRIP andthe reader device's serial number linked to the user's User ID.

From now on when the user wants to access the application provider'sapplication, the user is requested to log in by providing his/her UserID and an OTP generated by his/her reader device in conjunction withhis/her PKI device. The reader device generates OTPs as follows. Thereader device requests the user to insert his/her PKI device and toenter the PKI devices PIN. The reader device submits the PIN to the PKIdevice for verification. Then the reader device submits its readerdevice specific challenge to the PKI device and instructs the PKI deviceto digitally sign this challenge with the user's private key stored onthe PKI device. The reader device receives the resulting digitalsignature and derives the same PKRIP from that digital signature as thePKRIP that was derived for the registration phase. The reader generatesan OTP by cryptographically combining the PKRIP with a dynamic variable(such as the value of the reader device's real-time clock or a countermaintained by the reader device) and its reader device specificsymmetric reader secret using a symmetric cryptographic algorithm. Thereader device may for example concatenate the PKRIP and the dynamicvariable and encrypt the concatenation with the AES encryption algorithmusing the reader device specific symmetric reader secret as the AESencryption key, after which the reader device may decimalize a part(e.g. the first 3 bytes) of the resulting cryptogram and display theresult as the OTP on its display for the user to communicate to theapplication. In one embodiment, the reader device may feed the PKRIPvalue to an OTP generation algorithm which takes at least two dynamicvariables at least one of which is originally conceived to be anexternal dynamic variable (such as a challenge) and to which the readerdevice assigns the PKRIP values. For example the reader device may usean OTP algorithm that uses two dynamic variables: a first internaltime-based dynamic variable and a second external dynamic variable thatis originally conceived to be assigned a challenge value generated bythe application, whereby the reader device assigns the PKRIP value tothe second dynamic variable.

The authentication component of the application verifies the receivedOTP as follows. Using the User ID as a search key it retrieves the PKRIPvalue and the serial number of the reader device associated with theuser. Using the serial number of the user's reader device it determinesthe value of the reader device specific symmetric reader secret. Itdetermines the values of the dynamic variable used in the generation ofthe received OTP. It then cryptographically combines the retrieved PKRIPvalue and the determined value for the dynamic variable with thedetermined symmetric reader secret using a symmetric cryptographicalgorithm that is similar to the algorithm used by the reader devices.The result of this cryptographic combining is then compared to thereceived OTP. The authentication component may for example concatenatethe retrieved PKRIP value and the determined value for the dynamicvariable and encrypt the concatenation with the AES encryption algorithmusing the symmetric reader secret as the AES encryption key, after whichit may decimalize a part (e.g. the first 3 bytes) of the resultingcryptogram and check whether the result is the same as the received OTP.In one embodiment the authentication component comprises two layers. Afirst layer is an inner layer that is capable of verifying an OTPgenerated using a symmetric secret, a first dynamic variable and asecond dynamic variable that is originally conceived to be an externaldynamic variable e.g. a challenge. The inner layer has an interface thatexpects the OTP to be verified, the secret key and the value of theexternal dynamic variable. The second layer is an outer layer which iscalled by the application to verify the received OTP. The outer layercontains the symmetric reader secret and determines the user's PKRIPvalue and the reader device specific symmetric reader secret on thebasis of the User ID received from the calling application as describedabove. To verify the OTP the outer layer calls the inner layer andpasses the OTP and the symmetric reader secret and it passes the PKRIPvalue as the value for the second external dynamic variable. The innerlayer verifies the OTP and returns the result to the outer layer whichreturns the result to the application.

One advantage of this embodiment is the extra security offered by thefact that to generate valid OTPs one needs not only access to the user'sPKI device (and the PIN of the user's PKI device) but also the readerdevice that the user registered in the registration phase.

Other aspects of the invention are described below.

In some embodiments of the invention, as illustrated in FIG. 23, anauthentication device (2310) comprises a data input interface (2320) forreceiving data, a communication interface (2330) to exchange data,commands and responses with a separate removable security device (2390)capable of asymmetric cryptographic calculations (such as for example aPKI-enabled smart card), one or more data processing components (2340),one or more memory components (2345), a user input interface (2350) forreceiving data or instructions or other input from a user and a useroutput interface (2360) for presenting data (in particular OTPs and/orMACs) or messages or other output to a user.

The authentication device may be adapted to generate one-time passwords(OTPs) which may comprise message authentication codes (MACs).Henceforth, the terminology OTP may indicate not only OTPs in a narrowsense but also MACs unless otherwise specified. The authenticationdevice may be adapted to generate the one-time passwords bycryptographically combining a dynamic variable and a secret data elementthat the authentication device shares with a verifying entity such as anapplication or authentication server. In some embodiments theauthentication device may be adapted to generate the one-time passwordsby cryptographically combining a dynamic variable and a secret dataelement using a symmetric cryptographic algorithm parameterized with thesecret data element. In some embodiments the symmetric cryptographicalgorithm may comprise a symmetric encryption algorithm such as DES(Data Encryption Standard) or AES (Advanced Encryption Standard). Insome embodiments the symmetric cryptographic algorithm may comprise akeyed-hash algorithm such as a HMAC (keyed hash message authenticationcode) algorithm which may for example be based on the SHA-1 (Secure HashAlgorithm 1) algorithm or the MD5 (Message Digest 5) algorithm. Theshared secret data element to generate OTPs (and MACs) will henceforthbe referred to as the OTP key. The OTP key may also be referred to asthe OTP generation key especially when discussing usage of (the valueof) the OTP key for generating OTPs and/or MACs. The OTP key mayalternatively be referred to as the OTP verification key especially whendiscussing usage of (the value of) the OTP key for verifying thevalidity of an OTP or MAC. The OTPs and/or MACs may also be referred toas dynamic credentials and the OTP key may also be referred to as thedynamic credential generation key. In some embodiments the dynamicvariable may comprise or may be generated by the authentication devicefrom a challenge value and/or a counter value and/or a time value and/ortransaction data. In some embodiments the authentication device mayreceive the challenge and/or the transaction data from the user throughthe user input interface. In some embodiments the authentication devicemay comprise a real-time clock to provide time values for the generationby the authentication device of time-based OTPs. In some embodiments theauthentication device comprises a counter to provide counter values forthe generation by the authentication device of counter-based OTPs. Insome embodiments the authentication device provides a generated OTP tothe user through the user output interface e.g. in the form of a stringof numerical or alphanumerical characters that may for example bedisplayed on a display of the authentication device or that may beprovided to the user as synthesized speech.

In some embodiments the user input interface comprises a keyboard. Insome embodiments the user output interface comprises a display.

In some embodiments the data input interface comprises an opticalinterface. In some embodiments the data input interface comprises acamera for taking pictures (e.g. from a computer screen of an accessdevice). In some embodiments the authentication device is adapted todetect in a picture taken with a camera of the authentication device a2-dimensional image that encodes data in a particular format (forexample a QR-code or a 2-dimensional barcode). In some embodiments thedata input interface comprises an acoustical interface. In someembodiments the data input interface comprises a USB interface. In someembodiments the authentication device may be a medium sized compactmedium weight portable device i.e. a device with a maximal length of 15cm, a maximum width of 9 cm, a maximum thickness of 2 cm and a weight ofless than 200 gram.

In some embodiments the separate removable security device may be asmall compact lightweight portable device i.e. a device with a maximalextension in any dimension of 10 centimeter and a weight of less than100 gram. In some embodiments the separate removable security device maybe a smart card. In some embodiments the separate removable securitydevice may be an ISO/IEC 7810 ID-1 sized smart card. In some embodimentsthe removable security device may be a USB (Universal Serial Bus) key.

In some embodiments the communication interface is adapted to allow theuser to easily remove or replace the separate removable security devicethat the authentication device may be communicating with. In someembodiments the communication interface comprises an externallyaccessible slot for accepting and communicating with a removablesecurity device. In some embodiments the communication interfacerequires the user to insert the user's security device in such anexternally accessible slot for communicating with the user's securitydevice. In some embodiments the communication interface comprises asmart card interface and the separate removable security devicecomprises a smart card. In some embodiments the smart card may bePKI-enabled. In some embodiments the communication interface comprisesan externally accessible smart card reader. In some embodiments thecommunication interface may be adapted to accept an ISO/IEC 7810 ID-1sized smart card. In some embodiments the communication interface may beadapted to accept an ISO/IEC 7810 ID-3 sized smart card. In someembodiments the communication interface may be adapted to communicatewith a contactless smart card. In some embodiments communicationinterface may be adapted to communicate with a contact smart card. Insome embodiments the communication interface may be compatible with theISO/IEC 7816 specifications.

In some embodiments the one or more memory components may be adapted topermanently store data. In some embodiments the one or more memorycomponents may be adapted to (securely) store cryptographic secrets suchas for example symmetric or asymmetric decryption keys. In someembodiments the one or more memory components may be adapted to storesoftware and/or firmware. In some embodiments the one or more memorycomponents may be adapted to store configuration data. In someembodiments the one or more memory components may comprise RAM and/orROM memory.

In some embodiments the one or more data processing components maycomprise a processor and/or a controller for controlling the data inputinterface, the communication interface, the user input interface and/orthe user output interface. In some embodiments the one or more dataprocessing components may comprise a processing component adapted toperform cryptographic algorithms such as for example symmetric orasymmetric decryption algorithms. In some embodiments the one or moredata processing components may comprise an ASIC or an FPGA.

In some embodiments the authentication device does not (yet) comprise anOTP key that is associated with a particular user when theauthentication device is distributed to a user. In order to be able togenerate OTPs (which may comprise MACS) that can be verified in order toauthenticate the user or to authenticate transaction data submitted bythe user, the authentication device needs an OTP key that is also knownto the entity that will verify the OTPs and that is associated with theuser.

FIG. 24 illustrates a method (2400) according to an aspect of theinvention to generate OTPs and/or MACs for authenticating users and/ortransactions using an authentication device and a user's securitydevice.

In step 2410 a server component may determine the values of an OTP key(step 2411) and an initialization seed (step 2412) that aremathematically related. The server may associate (2415) the OTP key witha particular user. The initialization seed may be encrypted (2420) withthe public key of a public-private key pair the private key of which isstored on the user's security device using an asymmetric encryptionalgorithm such as for example the RSA (Rivest-Shamir-Adleman) algorithm.The encrypted initialization seed may be transferred (2425) to theuser's authentication device for example as part of an initializationmessage that may be received by the authentication device. The user'sauthentication device may then submit (2430) the encryptedinitialization seed to the user's security device to be decrypted, thesecurity device may decrypt the encrypted initialization seed with theuser's private key stored on the security device using an asymmetricdecryption algorithm such as for example RSA, and the security devicemay return the decrypted initialization seed to the authenticationdevice. The user's authentication device may then derive (2435) thevalue of the OTP key using the decrypted initialization seed. The user'sauthentication device may then use the OTP key value in the generation(2440) of OTPs and/or MACs as described above. In some embodiments theauthentication device communicates (2445) a generated OTP or MAC to theuser by means of its user output interface. The generated OTP or MAC maythen be communicated (2450) to for example a remote application forauthenticating the user or a user transaction to the remote application.The OTP or MAC thus received may then be verified (2460) by averification server component. The verification server component mayhave access to the value of the OTP key associated with the user and mayuse that OTP key value in the verification of the received OTP or MAC.Upon successful verification (2460) of the OTP or MAC the remoteapplication may take appropriate action (2470) such as granting accessto the user or accepting a transaction submitted by the user.

Initialization of the OTP Key—Server Side.

In some embodiments the determination of the value of the OTP key andthe provisioning of the OTP key value to the authentication device mayhappen as follows. An initialization server may determine, for a givenuser, the value of an OTP key and the value of at least oneinitialization seed that is mathematically related to the OTP key. Theserver may associate the user with the OTP key that is mathematicallyrelated to the initialization seed. Details on how the OTP key and theinitialization seed and the user may be interrelated and associated willbe discussed further on. The user is assumed to have a security devicecomprising a private key of a public-private key pair that is adapted todecrypt with an asymmetric cryptographic algorithm parameterized by theaforementioned private key data that have been encrypted with acorresponding asymmetric cryptographic algorithm parameterized with thepublic key of the aforementioned public-private key pair. The server mayobtain the public key of this public-private key pair that is associatedwith the user. For example the server may retrieve the public key from adatabase containing the public keys for a plurality of users. This stepmay require the user to provide a data element identifying the user, forexample a user id, or the user's name or the user's national id numberor the user's social security number or a serial number of the user'ssecurity device. For example in one embodiment a plurality of citizensmay have electronic national id cards comprising a public-private keypair and the server may have access to a central registry comprising thepublic keys associated with the citizens and may retrieve the public keyassociated with a particular user using the user's name of national idnumber. The server assembles an initialization message comprising atleast the initialization seed. The server encrypts with an asymmetriccryptographic algorithm parameterized with the public key associatedwith the user at least a part of the initialization message whereby theencrypted part of the initialization message comprises at least a partof the initialization seed.

The initialization message may also comprise other data elements such asfor example one or more nonces, or parts of the initialization seed thatare not encrypted with the public key associated with the user, or dataidentifying the user or the user's security device or the public keyassociated with the user, or data identifying the user's authenticationdevice. In some embodiments parts of the initialization message may beencrypted with an authentication device key that is associated with theuser's authentication device. In some embodiments this authenticationdevice key is a public key that corresponds to a private key known tothe authentication device. In some embodiments this authenticationdevice key is a secret key that is shared between the server and theauthentication device. In some embodiments the authentication device keyis shared between all authentication devices of a batch ofauthentication devices. In some embodiments each individualauthentication device may have its own individual value for theauthentication device key. In such embodiments the server may requiredata identifying the authentication device in order to determine theauthentication device key to use (for example by using theauthentication device identification data as a key derivation seed forgenerating the correct authentication device key or to search thecorrect authentication device key in a database). In some embodimentsparts of the initialization seed may be encrypted with theauthentication device key. In some embodiments parts of theinitialization seed may be encrypted both with the authentication devicekey and the user's public key. In some embodiments parts of theinitialization message that are encrypted both with the authenticationdevice key and the user's public key may first have been encrypted withthe authentication device key and then the user's public key. In someembodiments parts of the initialization message that are encrypted bothwith the authentication device key and the user's public key may firsthave been encrypted with the user's public key and then theauthentication device key.

The initialization message may then be made available to the user'sauthentication device.

In some embodiments the OTP key initialization process may be initiatedby the user. For example the user may contact the initialization serverusing an access device (such as a PC, laptop, tablet computer,smartphone . . . ) e.g. by accessing a web site or by sending an emailand in response the server may assemble an initialization message andsend the assembled initialization message to the user's access devicee.g. embedded in a web page or an email. In other embodiments theinitialization server may assemble proactively initialization messagesfor a plurality of users. In some embodiments the proactively assembledinitialization messages may be stored for future use. In otherembodiments the proactively assembled initialization messages may besent proactively to the appropriate users e.g. embedded in an email.

Transfer of the initialization message to the authentication device.

In some embodiments the initialization message is made available to anaccess device (e.g. a PC, laptop, tablet computer, smartphone . . . ) ofthe user. For example the initialization message may be sent to theuser's access device over the internet, for example embedded in a webpage or in an email. In some embodiments the initialization message maybe communicated by the user's access device to the suer's authenticationdevice. In some embodiments the initialization message may becommunicated, by the access device or by another device, to theauthentication device by means of a unidirectional communicationchannel. The access device may output a representation of theinitialization message over a human output interface of the user'saccess device. The access device may for example output theinitialization message on the access device's display e.g. encoded in animage, or encoded in a sequence of images, or encoded as a time-varyingoptical pattern, or the access device may for example output theinitialization message, using an audio output of the access device,encoded as a sequence of audible sounds. The authentication device maycapture this representation of the initialization message output by theaccess device. For example in one embodiment the authentication devicemay comprise an optical input interface e.g. comprising a camera and maycapture one or more images displayed by the user's access device andencoded with the initialization message (the images may for examplecomprise a QR code) and the authentication message may decode thecaptured images to obtain the initialization message. In anotherembodiment the authentication device may comprise an optical inputinterface e.g. comprising a plurality of optical detectors and may scana time-varying optical pattern displayed by the access device that isencoded with the initialization message and may decode the time-varyingoptical pattern to obtain the initialization message. In still anotherembodiment the authentication device may comprise an acoustical inputinterface and may capture a sequence of audible sounds emitted by theuser's access device that have been encoded with the initializationmessage and the authentication device may decode these sounds to obtainthe initialization message.

In some embodiments the authentication device stores the obtainedinitialization message for future processing. In other embodiments theauthentication device proceeds immediately with processing theinitialization message.

Initialization of the OTP Key—Authentication Device Side.

Retrieving the initialization seed from the initialization message

The authentication device obtains the initialization message prepared bythe initialization server, for example in one of the ways discussedabove. The authentication device may extract the initialization seedfrom the initialization message as follows. The authentication devicemay prompt the user to provide his or her security device to theauthentication device (for example in some embodiments theauthentication device may comprise a smart card reader and the user maybe prompted to insert his or her smart card in the authenticationdevice). The authentication device may extract at least some parts ofthe initialization message that have been encrypted with the user'spublic key. These parts of the initialization message that have beenencrypted with the user's public key and that the authentication deviceextracts from the initialization message may comprise at least the partsof the initialization seed that have been encrypted with the user'spublic key. The authentication device may submit these encrypted partsto the user's security device and may request the user's security deviceto decrypt the encrypted parts with the user's private key. The user'ssecurity device may decrypt the encrypted parts using the user's privatekey and an asymmetric decryption algorithm and return the now decryptedparts of the initialization message to the authentication device. Theauthentication device may receive the now decrypted parts of theinitialization message from the user's security device. Theauthentication device may also extract the parts of the initializationseed comprised in the initialization message that have not beenencrypted with the user's private key. The authentication device maythen assemble the initialization seed from the various parts of theinitialization seed that have been extracted from the initializationmessage.

In some embodiments the security device may be protected by a PIN. Insome embodiments the security device may require a PIN entry and verifythe correctness of the entered PIN prior to performing an asymmetriccryptographic operation involving a private key stored in the securitydevice. In some embodiments the authentication device may be adapted torequest the user to enter a PIN, to capture the PIN provided by the user(e.g. by means of the user input interface), and to communicate the PINprovided by the user to the security device for verification.

In some embodiments the initialization message (or parts thereof) mayalso have been additionally encrypted by the initialization server withanother key than the public key associated with the user. In suchembodiments the authentication device may decrypt the additionallyencrypted initialization message (or the additionally encrypted partsthereof) using a (secret) decryption key known to the authenticationdevice. In some embodiments the additional encryption is done with asymmetric encryption algorithm using a symmetric encryption key that isknown to both the initialization server and the authentication deviceand the authentication device may use this key to decrypt theadditionally encrypted initialization message. In other embodiments theencryption is done with an asymmetric cryptographic algorithm using apublic key the corresponding private key of which is known to theauthentication device and the authentication device decrypts theadditionally encrypted initialization message (or the additionallyencrypted parts thereof) using this private key.

In some embodiments the decryption key to decrypt this additionalencryption is unique for each authentication device and theinitialization server retrieves the appropriate encryption key e.g.using an identifier (such as a serial number of the user'sauthentication device) that the user may for example provide during theinitialization process. In some embodiments the decryption key is thesame for a group of authentication devices and the initialization serveronly needs to know the group of authentication devices that the user'sauthentication device belongs to to determine the correct encryptionkey. For example in some embodiments all authentication devices maybelong to the same group i.e. all authentication devices may share thesame decryption key.

Such an additional encryption can ensure that only a validauthentication device or even only a particular authentication devicecan retrieve the initialization seed from the initialization message.For example in some embodiments each authentication device has its ownunique decryption key and certain authentication devices may beblacklisted (e.g. because it is suspected that they have beencompromised or have fallen in the hands of malicious parties) and suchan additional encryption may ensure that initialization messages willonly be assembled for and can only be decrypted by authenticationdevices that are not blacklisted. In embodiments whereby eachauthentication device has its own unique decryption key this feature maybe used to ensure that an initialization message, even if it has beenintercepted, cannot be used with a different authentication device thenthe authentication device for which the initialization message wasintended.

In some embodiments the initialization message may comprise other dataelements that may enable the authentication device to verify whether thereceived initialization message is consistent, whether its integrity hasnot been compromised and/or whether the received message was indeedintended to be received by this authentication device. Theinitialization message may for example comprise an identifier if thetargeted authentication device, an error detection code, a redundancycode, a message authentication code and/or a signature that may beverified by the targeted authentication device.

In some embodiments the initialization message may comprise a dataelement that is relates to the user's public key or to a certificate ofthe user's public key.

The authentication device may process the initialization seed, forexample to determine the value of the OTP key, as discussed in moredetail below.

Relation between the initialization seed and the OTP key.

In some embodiments the initialization seed comprises the OTP key andboth the server and the authentication device may after theinitialization process simply store the OTP key for future use ingenerating or verifying OTPs.

In some embodiments the initialization server determines aninitialization seed and the initialization server and the authenticationdevice derive the same corresponding OTP key using correspondingderivation mechanisms. For example the initialization server and theauthentication server may use the same derivation mechanism to derivethe OTP key from the initialization seed.

In some embodiments the initialization server determines the OTP key andderives the corresponding initialization seed from the OTP key using afirst key derivation mechanism and the authentication device is adaptedto derive an OTP key value from the initialization mechanism using asecond derivation mechanism that is complementary with the firstderivation mechanism such that the authentication device derives thesame value for the OTP key as the OTP key value from which theinitialization server had derived the initialization seed. For examplein some embodiments the initialization server may derive theinitialization seed from an OTP key value by encrypting the OTP keyvalue and the authentication device may derive the OTP key value fromthe initialization seed by decrypting the initialization seed. In someembodiments the initialization server and the authentication deviceshare an encryption/decryption key and use a symmetricencryption/decryption algorithm. In some embodiments the initializationserver may use the shared encryption/decryption key to encrypt parts ofthe initialization message with a symmetric encryption algorithm. Insome embodiments the authentication device may use the sharedencryption/decryption key to decrypt parts of the initialization messagethat has been encrypted by e.g. the initialization server.

In some embodiments the derivation of the OTP key value from theinitialization seed by the authentication device may comprise using asecret data element known to the authentication device. In someembodiments this secret data element is shared with the initializationserver. In some embodiments this secret data element has a unique valuefor each individual authentication device. In some embodiments thissecret data element is shared by a group of authentication devices. Forexample in some embodiments the derivation of the OTP key value from theinitialization seed may comprise performing a bitwise exclusive oroperation on the initialization seed and a secret data element stored inthe authentication device.

In some embodiments the derivation of the OTP key value from theinitialization seed by the authentication device may comprise using adata element associated with the user's security device such as a dataelement related to a private key stored on the user's security device(for example the private key corresponding to the public key that wasused to encrypt parts of the initialization message). Such a dataelement related to a private key stored on the security device maycomprise the public key corresponding to that private key or anotherdata element from a public key certificate associated with that privatekey (such as the certificate serial number or the user's name or theuser's email address). This may provide a further link between the OTPkey value and the user's security device (and hence the user). In someembodiments the authentication device may obtain this extra data elementfrom the user security device e.g. by reading a data element such as thepublic key's certificate from the security device.

In some embodiments the derivation of the OTP key value may compriseusing an extra data element, which may be referred to henceforth asactivation code, that is e.g. determined by the initialization serverand provided to the user e.g. by means of an out-of-band channel such asa postal letter or an email or a text message (e.g. sms) to the user'scell phone and that the user then provides to the authentication deviceby means of the authentication device's human input interface. Theactivation code may for example comprise a string of characters. In someembodiments the activation code may comprise a PIN value.

In some embodiments, upon retrieving the initialization seed from theinitialization message, the authentication device may generate and storea data set that is associated with the OTP key and that comprises dataelements that the authentication device may use in subsequentgenerations and regenerations of the OTP key. In some embodiments theauthentication device's generation and regeneration of the OTP key usingdata elements comprised in this data set may comprise using the user'ssecurity device as will be explained in more detail below.

Life time of the OTP key.

In some embodiments the authentication device determines the value ofthe OTP key once using the initialization seed and the user's securitydevice as described above and stores the obtained OTP key value for anindefinite time so that it can be used for any subsequent OTP generationwithout a further need for the user's security device.

Usage of the security device to unlock the OTP key for usage ingenerating an OTP.

In some embodiments the OTP key has an unlimited life time but theauthentication device may require the user to present the securitydevice that was used to decrypt the initialization message as acondition for generating an OTP with the OTP key. For example, prior tousing the OTP key for generating an OTP, the authentication device mayprompt the security device to be presented and when a security device ispresented the authentication device may verify it is the correctsecurity device in a way that is similar to the embodiments discussedabove in connection to FIGS. 6-9. For example in some embodiments theauthentication devices may store a data element that allows theauthentication device to identify the correct security device (forexample a serial number of a public key certificate stored on thesecurity device) and may authenticate the security device by submittinga challenge to the security device for the security device to sign witha private key stored on the security device. The authentication devicemay verify the signature by using the corresponding public key andoptionally verifying the public key's certificate. In some embodimentsthe authentication device may store a challenge and a correspondingreference response, submit the challenge to the security device andcompare the response received from the security device with the storedreference response.

In some embodiments an obtained OTP key value may only have a limitedlife time after which the authentication device discards or deletes theOTP key value so that the authentication device must re-generate the OTPkey value for subsequent OTP generation. In some embodiments theauthentication device regenerates the OTP key value using a dataset thatis associated with the OTP key and that is stored by the authenticationdevice and that comprises data elements that the authentication devicemay use to regenerate the OTP key value (possibly using the user'ssecurity device).

In some embodiments the life time of the OTP key may be defined in termsof the real time elapsed after a certain event like the generation ofthe OTP key value or the first use of the OTP key value in thegeneration of an OTP. In other embodiments the life time of the OTP keymay be defined in terms of the number of times it has been used e.g. togenerate OTPs. In still other embodiments the generation of the OTP keyvalue by the authentication device may involve the use of the securitydevice of the user associated with the OTP key and the authenticationdevice may discard the generated OTP value when the user's securitydevice is removed from the authentication device.

Usage of the Security Device in Regenerating the OTP Key.

In some embodiments the (re)generation of the OTP key may require theauthentication device using the user's security device. In particular insome embodiments the (re)generation of the OTP key may comprise theauthentication device requesting the user's security device to performan asymmetric cryptographic operation with a user's private key storedon the security device. In some embodiments the same private key may beused for decrypting the initialization message as for regenerating theOTP key. In some embodiments the user's security device stores more thanone private key of more than one public/private key pair and a differentprivate key may be used for decrypting the initialization message thanfor regenerating the OTP key.

In some embodiments the authentication device uses the result of thisasymmetric cryptographic operation as input data in the algorithm forregenerating the OTP key. In some embodiments the authentication devicemay store a data element and for regenerating the OTP key theauthentication device may submit this stored data element to thesecurity device and the security device performs an asymmetriccryptographic operation with its private key on this submitted dataelement and returns the result to the authentication device which usesthis returned result in subsequent calculations for regenerating the OTPkey. I.e. in some embodiments the regenerated OTP key may be a functionof the private key of the security device and a value stored in theauthentication device.

In some embodiments if another security device (with another privatekey) is presented to the authentication device, the authenticationdevice may nevertheless generate an OTP key which however will then havea different value than the correct OTP key (since the private key ofthat other security device is different) such that when theauthentication device thereafter uses this different OTP key to generatean OTP, the generated OTP will also be incorrect and will be rejected inthe verification process. In some embodiments the authentication devicestores a data element that allows the authentication device to identifyor recognize the correct security device and warns the user if anincorrect or unexpected security device is presented.

In some embodiments the authentication device may store a value that isencrypted with the user's public key, and to regenerate the OTP key theauthentication device may request the user's security device to decryptthis stored value with the user's private key whereupon the securitydevice can use this decrypted value to regenerate the OTP value.

For example in some embodiments the authentication device may determinea value from which it may regenerate the OTP key, encrypt that valuewith the user's public key, and store the encrypted value. To regeneratethe OTP key the authentication device may request the user's securitydevice to decrypt this stored (encrypted) value with the user's privatekey whereupon the security device can use this decrypted value toregenerate the OTP value. In some embodiments the authentication devicemay obtain this public key from the security device, for example duringthe initialization of the authentication device. In some embodiments theauthentication device may store this public key for later use, forexample in a data set associated with the OTP key.

In some embodiments the stored value that is encrypted with the publickey may comprise the OTP key itself. In other embodiments the storedvalue that is encrypted with the public key may comprise an intermediatevalue that may be used by the authentication device to regenerate theOTP key. For example in some embodiments, prior to discarding the OTPkey, the authentication device determines an intermediate symmetricencryption key (which may for example be a random number), encrypts theOTP key with a symmetric encryption algorithm using the intermediatesymmetric encryption key, encrypts the intermediate symmetric encryptionkey with an asymmetric encryption algorithm using the private key of thesecurity device, stores the encrypted OTP key and the encryptedintermediate symmetric encryption key, and may then discard the clearvalues of the OTP key and the intermediate symmetric encryption key.Thereafter, when the authentication device needs to regenerate the OTPkey, it submits to the security device the stored encrypted intermediatesymmetric encryption key that was encrypted with the public key of thesecurity device. The security device then decrypts this encryptedintermediate symmetric encryption key with its private key and returnsthe decrypted intermediate symmetric encryption key to theauthentication device. The authentication device then uses theintermediate symmetric encryption key to decrypt the encrypted OTP key.In some embodiments rather than encrypting and storing the OTP keyitself with such an intermediate symmetric encryption key, theauthentication key may encrypt and store some intermediate derivationseed. This may for example be done in the case of embodiments that alsouse other data elements in the regeneration of the actual OTP key.

In other embodiments the authentication device may for example store achallenge and may request the user's security device to sign thatchallenge with the user's private key. The authentication device maythen derive the OTP key using the signature that the security deviceproduced over that challenge.

For example in some embodiments, prior to discarding the OTP key, theauthentication device determines a challenge, submits the challenge tothe security device to be signed by the private key of the securitydevice, derives an intermediate encryption key from the signaturegenerated by the security device over this challenge, encrypts the OTPkey with this intermediate encryption key, stores the encrypted OTP keyand then may discard the clear value of the OTP key. Thereafter, whenthe authentication device needs to regenerate the OTP key, it submits tothe security device the same challenge. The security device signs thesubmitted challenge and returns the signature to the authenticationdevice. The authentication device may then derive the intermediateencryption key from this signature and use it to decrypt the encryptedOTP key. In some embodiments rather than encrypting and storing the OTPkey itself with such an intermediate symmetric encryption key, theauthentication key may encrypt and store some intermediate derivationseed. This may for example be done in the case of embodiments that alsouse other data elements in the regeneration of the actual OTP key. Insome embodiments the challenge may be a fixed value that may behardcoded. In some embodiments the challenge may be a random value andthe authentication device stores the challenge. In some embodiments theauthentication device may use the same challenge every time it discardsthe OTP key. In other embodiments the authentication device may, everytime or only sometimes, determine a different value for the challengewhen it discards the OTP key.

In some embodiments the authentication device always presents the samestatic value to the user's security device to regenerate the value of acertain OTP key. For example the authentication device determines duringthe initialization process for a certain OTP key a value (e.g. achallenge or a value encrypted with the user's public key) that itstores and that it subsequently will not change anymore for thatparticular OTP key and that it presents to the user's security device(e.g. to be signed with the user's private key or to be decrypted by theuser's private key) to obtain a second value that it then uses to(re)generate the OTP key.

In some embodiments the authentication device may update this storedvalue from time to time. In some embodiments this stored value may beupdated after a certain number of OTP key regenerations (for example atevery regeneration). In some embodiments the authentication deviceupdates the stored value together with some other data elements suchthat the authentication device can still regenerate the same OTP keyusing the updated values of the stored value and the other dataelements. The authentication device may for example store for each OTPkey that it supports the stored value and the other data elements in adata set associated with the OTP key. For example in some embodimentswhen the authentication device regenerates the OTP key (or moregenerally when the authentication device updates the stored dataelements for regenerating that are used for regenerating the OTP keywhich henceforth will be referred to as the regeneration data), theauthentication device may determine from the stored values of theregeneration data a value, which will be further referred to as theintermediate derivation value, from which the OTP key value can bederived (for example the OTP key value itself or the originalinitialization seed or some other intermediate value). Then theauthentication device may generate a random (or pseudo-random) value.

In some embodiments this random value is stored as the updated value forthe challenge and the authentication device submits this updatedchallenge to the user's security device to be signed. The authenticationdevice may then calculate a value, referred to as a compensation value,from the intermediate derivation value and the generated signature overthe updated challenge. The authentication device may store thiscompensation value along with the updated challenge. This compensationvalue may be calculated by the authentication device such that theauthentication device can regenerate later on the original value of theintermediate derivation value from the user's security device'ssignature over the stored updated challenge and the stored compensationvalue. For example the authentication device may calculate thecompensation value by performing a bitwise exor on the intermediatederivation value and certain parts of the signature over the updatedchallenge. Later on the authentication device can then regenerate theintermediate derivation value (and therefrom subsequently also the OTPkey) by letting the user's security device sign the stored updatedchallenge and then perform a bitwise exor of the stored compensationvalue and the earlier mentioned certain parts of the signature.

In other embodiments the authentication device may calculate acompensation value from the intermediate derivation value and the randomvalue and stores this compensation value. This compensation value may becalculated by the authentication device such that the authenticationdevice can regenerate later on the original value of the intermediatederivation value by combining the random value and the storedcompensation value. The authentication device may encrypt the randomvalue with the user's public key and may store this encrypted randomvalue. Later on the authentication device may regenerate the originalintermediate derivation value by first requesting the user's securitydevice to decrypt the encrypted random value with the user's private keyand then combining the decrypted random value with compensation value.For example in some embodiments the authentication device may calculatethe compensation value by performing a bitwise exor of the random valueand the original intermediate derivation value and similarly mayregenerate later on the original intermediate derivation value byperforming a bitwise exor of the decrypted random value and the storedcompensation value.

In still some other embodiments the authentication device may be adaptedto (re)generate the OTP key from a first value that it stores and asecond value that it derives from a data element that is(cryptographically) related to the public key of the security device andthat may be stored on the security device. To regenerate the OTP keyafter it has been discarded, the authentication device may prompt theuser to present his or her security device. The authentication devicemay obtain the public key related data element. The authenticationdevice may authenticate the security device by means of achallenge-response method based on a cryptographic operation by thesecurity device with the private key corresponding to the public key.The authentication device may for example submit a challenge to thesecurity device to be signed by the security device and theauthentication device may verify this signature. Upon successfulauthentication of the security device the authentication device mayderive the second value from the data element related to the public keyobtained from the security device, and use the derived second valuetogether with the stored first value to regenerate the OTP key. In someembodiments the data element related to the public key may be the publickey itself. In some embodiments the data element related to the publickey may be a data element from the certificate of the public key thatthe authentication device receives from the security device along withthe public key itself and authenticating the security device maycomprise verifying this certificate. In some embodiments the first valuethat is stored by the authentication device may be the initializationseed extracted from the initialization message.

In some embodiments discarding the OTP key may comprise erasing thevalue of the OTP key from the memory component(s) of the authenticationdevice.

In other embodiments when the authentication device discards the OTPkey, the authentication device does not erase it from its memorycomponent(s) but instead inactivates the OTP key in memory (e.g. bysetting a flag associated with the OTP key that indicates its inactivestatus). Regenerating the OTP key may then comprise reactivating the OTPkey in memory (e.g. by resetting the flag associated with the OTP key toindicate that the status of the OTP key is active), rather thenre-calculating or re-deriving the value of the OTP key. In someembodiments the authentication device stores along with the OTP key anidentification data element that is cryptographically linked to thepublic key of a public/private key pair on the user's security device(i.e. a data element that is linked to a public key that corresponds toa private key that is stored on the same security device that was usedto decrypt the initialization value that was used by the authenticationdevice to derive or determine the value of the OTP key; this dataelement may be linked to such a public key by means of the public key'scertificate; this data element may for example comprise the user's nameor a certificate serial number or that public key itself). In someembodiments, as a necessary condition to re-activate the OTP key, theauthentication device may require the user's security device that isassociated with the OTP key and may read the public key and/orcertificate of that public key that the identification data element islinked to and may authenticate the security device by performing achallenge-response authentication using that public key (e.g. sending achallenge to the security device to be submitted to an asymmetriccryptographic operation by the security device using the private keycorresponding to the public key, such as a signing operation, and usingthe public key to verify the result i.e. the response of thischallenge-response authentication). In some embodiments theauthentication device may also verify the certificate of this publickey. In some embodiments this public key is the same public key thatcorresponds to the private key that was used to decrypt theinitialization seed.

Support for Multiple Users and Multiple Applications.

In some embodiments the authentication device only supports one OTP keyand the authentication device can only be used with one user and thesame OTP key is used for all applications that the user accesses byusing OTPs generated by the authentication device.

In other embodiments the authentication device can support multiple OTPkeys. For example the authentication device may store multiple data setswhereby each data set is associated with a different OTP key and wherebyeach data set comprises data that the authentication device may use toobtain the OTP key that the data set is associated with.

Support for Multiple Applications.

In some embodiments the authentication device can support more than oneOTP key and different OTP keys for the same user can be associated withdifferent applications. For example the authentication device may storemultiple data sets whereby each data set is associated with a differentOTP key and whereby each data set comprises data that the authenticationdevice may use to obtain the OTP key that the data set is associatedwith and whereby each data set also comprises an application identifier.The authentication device may use these application identifiers toassist the user in selecting the appropriate OTP key when generating anOTP for a specific application. For example the application identifiermay comprise an application name and the authentication device may usethe application names in a menu that it presents to the user so that theuser can select for which application the authentication device shouldgenerate an OTP. In some embodiments the initialization messagecomprising the initialization seed for the OTP key associated with acertain application may also comprise such an application identifier.

In some embodiments a single initialization message may comprise theinitialization data (such as the initialization seed and an applicationidentifier) for more than one application.

In some embodiments application web servers may point out to users howthey can initiate the initiation process to personalize theirauthentication devices with an OTP key suitable for that application.For example the login page of an application's web server may comprise alink to an initialization server. If the user follows that link theinitialization server will start the initialization process with thatuser.

Support for Multiple Users.

In some embodiments the authentication device can support more than oneOTP key and different OTP keys can be associated with different users.For example the authentication device may store multiple data setswhereby each data set is associated with a different OTP key wherebyeach data set comprises data that the authentication device may use toobtain the OTP key that the data set is associated with and whereby eachdata set also comprises a data element associated with the user. Thisdata element associated with the user may for example comprise a useridentifier (e.g. the user's national id number or the user's socialsecurity number), or it may comprise an identifier of the user'ssecurity device or it may comprise an identifier associated with theuser's private key on the user's security device such as for example aserial number of a certificate associated with the user's private key.In some embodiments, when the user presents his or her security deviceto the authentication device, the authentication device may retrieve andcompare data stored on the security device (such as the user's nationalid or a serial number of a certificate) with the corresponding userassociated data elements in the various data sets stored in theauthentication device that are associated with the various OTP keys thatthe authentication device supports. In this way the authenticationdevice may determine and select the data sets that can be used with thegiven security device that a current user of the authentication devicepresents to the authentication device and may thus distinguish thesedata sets from data sets that are associated with security devices ofother users that may at times use the same authentication device.

In some embodiments when a user presents his or her security device tothe authentication device the authentication device may verify whetherit already has a data set associated with that security device. If thatis not the case the authentication device may suggest the user to startan initialization process to obtain an initialization message so thatthe authentication device may construct a data set for the givensecurity device.

Support for Extra Authentication Devices.

In some embodiments the initialization server can assemble more than oneinitialization message for different authentication devices such thatthey will generate the same OTP key. In that way a user can initializemore than one authentication device and can use any one of them at willwith his or her security device to generate valid OTPs.

One aspect of the invention provides an apparatus comprising anauthentication device for generating dynamic credentials that comprisesa processing component adapted to generate a dynamical credentialcomprising a one-time password and/or a message authentication codeusing a symmetric cryptographic algorithm that cryptographicallycombines a secret credential generation key with the value of a dynamicvariable, a memory component for storing permanently or temporarily thesecret credential generation key, a user input interface for receivinginputs from a user, a communication interface for communicating with asecurity device of said user that comprises a memory for securelystoring the first private key of a first public/private key pairassociated with said user and that is adapted to perform asymmetriccryptographic calculations with said first private key wherein saidasymmetric cryptographic calculations comprise at least an asymmetriccryptographic decryption operation, a data input interface for receivingan initialization message comprising at least an initialization seed atleast a first part of which is encrypted with the first public key ofsaid first public/private key pair; whereby the authentication device isadapted to extract at least said first encrypted part of theinitialization seed from the initialization message, to submit (usingthe communication interface) the first encrypted part of theinitialization seed to the security device of said user for the securitydevice to decrypt said first encrypted part of the initialization seedusing said private key and said asymmetric cryptographic decryptionoperation, to receive (using the communication interface) from thesecurity device the first part of the initialization seed decrypted bythe security device, and to derive the value of said secret credentialgeneration key from at least said decrypted first part of theinitialization seed and to store said derived value of said secretcredential generation key at least temporarily in said memory component.

In some embodiments the first encrypted part of the initialization seedmay comprise the entire initialization seed. In some embodiments theinitialization seed may comprise or may be the secret credentialgeneration key.

In some embodiments the authentication device may be further adapted tolimit the life-time of the secret credential generation key. In someembodiments the authentication device is adapted to determine whetheraccording to certain criteria the life-time of the secret credentialgeneration key has been exceeded. In some embodiments the authenticationdevice may be further adapted to discard the secret credentialgeneration key after it has been determined that the life-time of thesecret credential generation key has been exceeded. In some embodimentsthe authentication device discarding the secret credential generationkey may comprise the authentication device erasing the value of thesecret credential generation key from the memory component. In someembodiments the life-time of the secret credential generation key isdefined in terms of the time elapsed since a particular event and theauthentication device may discard the secret credential generation keyafter that time has elapsed. For example the authentication device maydiscard the secret credential generation key a fixed time (e.g. an hour)after its value has been obtained by the authentication device. In someembodiments the life-time of the secret credential generation key isdefined in terms of the number of times its value has already been usedfor generating dynamical credentials since that value has been obtainedby the authentication device. For example the authentication device maybe adapted to count the number of times it has used the secretcredential generation key after it has obtained its value and to discardthat value when that number exceeds a certain fixed threshold. In someembodiments the secret credential generation key is discarded after ithas been used once. In some embodiments the life-time of the secretcredential generation key is defined in terms of certain events. Forexample in some embodiments the authentication device may require thepresence of said security device for the generation of dynamiccredentials and may discard the secret credential generation key uponremoval of the security device.

In some embodiments the authentication device may be further adapted toregenerate the value of the secret credential generation key after ithas been discarded. In some embodiments the authentication device isadapted to store in the memory component a data set associated with thesecret credential generation key that comprises a first regenerationvalue, and the authentication device regenerating the value of thesecret credential generation key comprises the authentication devicesubmitting to said user's security device said first regeneration valuefor said user's security device to process said first regeneration valuewith an asymmetric cryptographic algorithm using the second private keyof a second public/private key pair stored in the user's securitydevice, receiving from the user's security device the resulting value ofsaid processing by the user's security device of the first regenerationvalue using said second private key, and deriving the value of thesecret credential generation key from said first resulting value. Insome embodiments said second public/private key pair may be the same assaid first public/private key pair.

In some embodiments said first regeneration value comprises said firstencrypted part of the initialization seed. In some embodiments saidfirst regeneration value comprises the secret credential generation keyencrypted with the second public key corresponding to said secondprivate key and regenerating the value of the secret credentialgeneration key comprises the authentication device submitting to saiduser's security device the encrypted secret credential generation keyfor said user's security device to decrypt the encrypted secretcredential generation key using said second private key of said secondpublic/private key pair stored in the user's security device. In someembodiments said first encrypted part of the initialization seedcomprises the secret credential generation key. In some embodiments theauthentication device regenerating the value of the secret credentialgeneration key comprises the authentication device submitting to saiduser's security device the first encrypted part of the initializationseed for said user's security device to decrypt the first encrypted partof the initialization seed using said first private key of said firstpublic/private key pair stored in the user's security device.

In some embodiments the authentication device is adapted to determinethe first regeneration value prior to discarding the secret credentialgeneration key. In some embodiments the authentication device determinesthe first regeneration value by encrypting with the public keycorresponding to said second private key a value that the authenticationdevice can use to regenerate the secret credential generation key. Insome embodiments this value may comprise the secret credentialgeneration key.

In some embodiments said data set associated with the secret credentialgeneration key also comprises a second regeneration value and theauthentication device is further adapted to regenerate the secretcredential generation value using said second regeneration value andsaid first resulting value. In some embodiments the second regenerationvalue comprises a regeneration seed encrypted with a regenerationencryption key using a symmetric encryption algorithm. In someembodiments the authentication device regenerating the secret credentialgeneration key comprises the authentication device submitting the firstregeneration value to the security device for the security device tosign using an asymmetric signature algorithm and said second privatekey, receiving the resulting signature, deriving the regenerationencryption key from said resulting signature, using the derivedregeneration encryption key to decrypt with a symmetric decryptionalgorithm the second regeneration value to obtain said regenerationseed, and deriving the secret credential generation value from thedecrypted regeneration seed. In some embodiments the regeneration seedmay comprise the initialization seed. In some embodiments theregeneration seed may comprise the secret credential generation key.

In some embodiments the authentication device is adapted to determinethe first regeneration value and the second regeneration value prior todiscarding the secret credential generation key. In some embodiments theauthentication device determines the first regeneration value bychoosing a challenge and determines the second regeneration value bydetermining a regeneration seed and a regeneration encryption key andencrypting said regeneration seed with said regeneration encryption keyto obtain the second regeneration value, whereby the authenticationdevice determines the regeneration encryption key by submitting thefirst regeneration value to the security device for the security deviceto sign using an asymmetric signature algorithm and said second privatekey, receiving the resulting signature, deriving the regenerationencryption key from said resulting signature and whereby theregeneration seed is determined to be a value that is related to thesecret credential generation key such that the authentication device canderive the secret credential generation key from said regeneration seed.In some embodiments the regeneration seed comprises the initializationseed. In some embodiments the regeneration seed comprises the secretecredential generation key.

In some embodiments the authentication device may be further adapted tocapture a signal that is output or emitted by the human output interfaceof an access device of the user and that encodes a representation of theinitialization message, and the authentication device may be furtheradapted to extract and decode the initialization message from thecaptured signal. In some embodiments the authentication device comprisesa camera and the authentication device is adapted to take a picture withthat camera of an image encoding the initialization message and beingdisplayed on the display of the access device and the authenticationdevice is adapted to extract the image from the picture taken with thecamera and to decode the image to obtain the initialization messageencoded in the image. In some embodiments the authentication devicecomprises a microphone and the authentication device is adapted torecord with that microphone an acoustic signal encoding theinitialization message and being emitted by a loudspeaker of the accessdevice and the authentication device is adapted to extract and decodethe initialization message from the acoustic signal.

In some embodiments the symmetric cryptographic algorithm for generatingthe dynamic credential may comprise a hashing algorithm. For example insome embodiments the symmetric cryptographic algorithm may comprise akeyed hashing algorithm that is parameterized with the secret credentialgeneration key and that takes the value of the dynamic variable asinput. For example in some embodiments the symmetric cryptographicalgorithm may comprise a symmetric encryption algorithm that isparameterized with the secret credential generation key and thatencrypts a value derived from the dynamic variable.

In some embodiments the dynamic variable may be derived from a timevalue. In some embodiments the authentication device may comprise aclock to provide a time value that may be used by the authenticationdevice to determine the value of the dynamic variable. In someembodiments the dynamic variable may be derived from a counter value. Insome embodiments the authentication device may store and maintain thiscounter and update the counter upon specific events. In some embodimentsthe authentication device may update the counter value each time thatthe authentication device generates a dynamic credential. For example insome embodiments the authentication value may increment the counterbefore or after each credential generation. In some embodiments thedynamic value may be derived from a value that is stored and maintainedby the authentication device and that is updated by the authenticationdevice at certain events. For example the authentication device mayupdate this event related value by submitting the current value to ahash algorithm and replacing the current value by the result of thishash algorithm. In some embodiments the dynamic variable may be derivedfrom challenge that is generated externally to the authentication deviceand that is provided to authentication device. In some embodiments theuser input interface may be adapted to receive the challenge provided tothe authentication device by the user. In some embodiments the dynamicvariable may be derived from transaction data that may represent atransaction that the user wants to submit to an application and that areprovided to the authentication device. In some embodiments the userinput interface may be adapted to receive the transaction data providedto the authentication device by the user

In some embodiments the authentication device may comprise a user outputinterface. In some embodiments the authentication device may be adaptedto use the user output interface to communicate the generated dynamiccredential to the user. In some embodiments the user output interfacemay comprise a display and the authentication device may present thegenerated dynamic credential to the user formatted as a string ofcharacters. In some embodiments the string of characters comprises onlydecimal digits. In some embodiments the string of characters comprisesalphanumerical digits.

Another aspect of the invention provides a method to initialize anauthentication device of a particular user with a secret credentialgeneration key for generating dynamic credentials, the method comprisingthe steps of: determining at a server a secret credential generation keyand an initialization seed whereby the secret credential generation keyand the initialization seed are mathematically linked by an algorithmthat allows to derive the secret credential generation key from theinitialization seed, associating at the server the secret credentialgeneration key with said particular user, encrypting at the server atleast a first part of the initialization seed with an asymmetricencryption algorithm using the public key of a public/private key pairof which the private key is stored on a security device of said user,assembling at the server an initialization message comprising saidencrypted first part of the initialization seed and any other part ofthe initialization seed, sending said initialization message to theauthentication device of the user, receiving at said authenticationdevice the initialization message, extracting at the authenticationdevice the encrypted first part of the initialization seed and any otherpart of the initialization seed from the received initializationmessage, communicating at the authentication device with a securitydevice of the user presented to the authentication device by the uses,submitting by the authentication device the encrypted first part of theinitialization seed to said security device, decrypting at said securitydevice the encrypted first part of the initialization seed with saidprivate key and returning the decrypted first part of the initializationseed to the authentication device, receiving at the authenticationdevice the decrypted first part of the initialization seed, and derivingat the authentication device the secret credential generation key fromthe initialization seed.

In some embodiments determining at the server the secret credentialgeneration key and the initialization seed comprises choosing a valuefor the initialization seed and calculating the secret credentialgeneration key from the chosen value of the initialization seed. Forexample the secret credential generation key may have the same value asthe chosen value of the initialization seed, or may be calculated as aone-way hash function of the chosen value of the initialization seed. Insome embodiments determining at the server the secret credentialgeneration key and the initialization seed comprises choosing a valuefor the secret credential generation key and calculating theinitialization seed from the chosen value of the secret credentialgeneration key. For example the initialization seed may be calculated byencrypting the chosen value of the secret credential generation key withan encryption key the corresponding decryption key of which is known tothe authentication device.

In some embodiments the method comprises the additional step of storingat least temporarily the derived secret credential generation key in amemory component of the authentication device.

In some embodiments the method comprises the additional steps of:encrypting at the server at least a second part of the initializationseed using an encryption key that matches a decryption key known to theauthentication device and decrypting at the authentication device saidsecond part of the initialization seed with said decryption key. In someembodiments the value of said decryption key is particular to saidparticular authentication device. In some embodiments the authenticationdevice shares the value of said decryption key with other authenticationdevices.

In some embodiments the step of sending said initialization message toan authentication device of the user comprises the server sending theinitialization message to an access device of the user and the accessdevice emitting over a human output interface of the access device asignal encoded with a representation of the initialization message, andthe step of receiving at said authentication device the initializationmessage comprises the authentication device capturing said signal anddecoding said signal to obtain the representation of said initializationmessage. In some embodiments the authentication device comprises acamera and the access device comprises a display and the representationof the initialization message comprises a two-dimensional image and themethod comprises the additional steps of the access device displayingsaid two-dimensional image on the display of the access device and theauthentication device making a picture of said image, extracting saidtwo-dimensional image from said picture and decoding the image to obtainthe initialization message.

In some embodiments the authentication device may comprise any of theauthentication devices for generating dynamic credentials that have beendescribed above.

Yet another aspect of the invention provides a method for generating afirst dynamic credential by an authentication device and a securitydevice of a particular user, the method comprising the steps of:initializing said authentication device of said particular useraccording to any of the methods method to initialize an authenticationdevice of a particular user with a secret credential generation key forgenerating dynamic credentials described above, obtaining a value of adynamic variable, and determining said first dynamic credential as theresult of cryptographically combining said value of said dynamicvariable with said secret credential generation key using a symmetriccryptographic algorithm.

In some embodiments the method for generating a first dynamic credentialcomprises the additional step of deriving said value of said dynamicvariable from a time-related value. In some embodiments the method forgenerating a first dynamic credential comprises the additional step ofderiving said value of said dynamic variable from a counter that ismaintained and updated by the authentication device. In some embodimentsthe method for generating a first dynamic credential comprises theadditional step of deriving said value of said dynamic variable from achallenge that may be generated externally to the authentication deviceand that may be provided to the authentication device. In someembodiments the authentication device receives the challenge from theuser by means of a user input interface of the authentication device. Insome embodiments the method for generating a first dynamic credentialcomprises the additional step of deriving said value of said dynamicvariable from transaction data representing a transaction that the userwants to be performed by an application that may for example be hostedby a remote application server. In some embodiments the authenticationdevice receives said transaction data from the user by means of a userinput interface of the authentication device. In some embodiments theauthentication device receives the transaction data via a data inputinterface of the authentication device and presents the transaction datato the user for review by means of a human output interface of theauthentication device and captures an approval of the user for thepresented transaction data by means of a human input interface of theauthentication device.

In some embodiments the method for generating a first dynamic credentialcomprises the additional steps of: the authentication device generatinga representation of said generated dynamic credential that can bepresented to the user, and the authentication device presenting saidrepresentation to the user by means of a human output interface of theauthentication device.

In some embodiments the method for generating a first dynamic credentialcomprises the additional steps of: the authentication device verifyingagainst a set of criteria whether the life-time of said secretcredential generation key has expired, and the authentication device, ifsaid life-time has expired, discarding, possibly after said generationof said first dynamic credential, said secret credential generation key.In some embodiments said discarding may comprise the authenticationdevice erasing the secret credential generation key from a memorycomponent of the authentication device. In some embodiments saiddiscarding may comprise the authentication device inactivating thesecret credential generation key stored in a memory component of theauthentication device.

In some embodiments the method for generating a first dynamic credentialcomprises the additional steps of: the authentication device, prior togenerating a second dynamic credential using said the secret credentialgeneration key, regenerating the secret credential generation key. Insome embodiments regenerating the secret credential generation keycomprises: the authentication device requiring the presence of thesecurity device of the user and communicating with the security device,the authentication device submitting a first regeneration value to thesecurity device, the security device receiving said first regenerationvalue and using the received first regeneration value as input for anasymmetric cryptographic operation parameterized with a second privatekey stored on the security device of a second public/private key pairassociated with the user, the security device returning to theauthentication device the result of said asymmetric cryptographicoperation by the security device, and the authentication device usingsaid result.

In some embodiments said using by the authentication device of saidresult comprises the authentication device verifying said result. Insome embodiments said asymmetric cryptographic operation by the securitydevice comprises the generation of a signature over the received firstregeneration value with an asymmetric cryptographic signature algorithmparameterized with said second private key, said result comprises saidsignature, and verification of said result by said authentication devicecomprises verifying said signature comprised in said result. In someembodiments the first regeneration value comprises a random challengegenerated by the authentication device. In some embodiments saiddiscarding of the secret credential generation key by the authenticationdevice may comprise the authentication device inactivating the secretcredential generation key stored in a memory component of theauthentication device and the usage by the authentication device of saidresult of said asymmetric cryptographic operation by the security devicemay comprise reactivating the secret credential generation key stored ina memory component of the authentication device if said verification ofthe result was successful.

In some embodiments the authentication device determines, possibly priorto said discarding of the secret credential generation key, anintermediate value, and said first regeneration value comprises saidintermediate value encrypted with an asymmetric encryption algorithmparameterizes with a second public key that corresponds to said secondprivate key of said public/private key pair. In some embodiments saidasymmetric cryptographic operation by the security device comprises thedecryption of the received first regeneration value with an asymmetricdecryption algorithm parameterized with said second private key, saidresult comprises the decrypted intermediate value, and usage by theauthentication device of said result comprises the authentication deviceusing the decrypted intermediate value to obtain the value of the secretcredential generation key. In some embodiments the intermediate valuecomprises the secret credential generation key. In some embodiments theintermediate value comprises the initialization key.

In some embodiments the authentication device determines, possibly priorto said discarding of the secret credential generation key, a secondregeneration value, and the usage by the authentication device of saidresult of said asymmetric cryptographic operation by the security devicecomprises the authentication device mathematically or cryptographicallycombining said second regeneration value with said result to determinethe value of the secret credential generation key. In some embodimentssaid determination of the second regeneration value comprisesdetermining an intermediate regeneration seed and encrypting theintermediate regeneration seed with an intermediate encryption key, andthe second regeneration value comprises the intermediate regenerationseed encrypted with the intermediate encryption key, and the usage bythe authentication device of said result of said asymmetriccryptographic operation by the security device comprises deriving fromsaid result an intermediate decryption key that matches saidintermediate encryption key and decrypting said encrypted intermediateregeneration seed and deriving the value of the secret credentialgeneration key from the decrypted intermediate regeneration seed. Insome embodiments the intermediate regeneration seed comprises thesecrete credential generation key. In some embodiments the intermediateregeneration seed comprises the initialization seed. In some embodimentsthe authentication device determines the value of the intermediatedecryption key (for example as a random number) and determines saidfirst regeneration value by encrypting the intermediate decryption keywith said second public key and the authentication device recovers theintermediate decryption key by submitting the first regeneration valueto the security device to be decrypted by the second private key. Insome embodiments the authentication device determines the firstregeneration value (e.g. as a random number), and determines the valueof the intermediate encryption key a first time by submitting the firstregeneration value to the security device to be signed by the secondprivate key and deriving the intermediate encryption key from theresulting signature, uses the intermediate encryption key to determinethe second regeneration value by encrypting the intermediateregeneration seed with the intermediate encryption key as describedabove, stores the first regeneration value and the second regenerationvalue, and regenerates the secret credential generation key as describedabove by regenerating the intermediate encryption key by re-submittingthe first regeneration value to the security device to be signed by thesecond private key and re-deriving the intermediate encryption key fromthe resulting signature and using the regenerated intermediateencryption key to decrypt the second regeneration value to obtain thevalue of the intermediate regeneration seed, and derives the secretcredential generation key from the obtained value of the intermediateregeneration seed.

Still another aspect of the invention provides a method of using anauthentication device such as the authentication devices described abovefor securing an interaction between a user and a remote applicationserver, the method comprising the steps of: receiving at the applicationserver a request of the user, generating at the authentication device atthe request of the user a dynamic credential according to any of themethods for generating dynamic credentials described above, makingavailable to a verification server the secret dynamic credentialgeneration key associated with the user, receiving the generated dynamiccredential at the verification server, verifying at the verificationserver the validity of the received dynamic credential using said secretdynamic credential generation key, and granting at the remoteapplication server said request if the received dynamic credential isverified to be valid.

Advantages of Aspects of the Invention

The advantage of certain embodiments of the invention is that the servernever needs to have access to the user's security device (the serveronly needs to be able to obtain the user's public key) and the serverdoesn't need to keep track of which authentication device is being usedby which user. In particular the server has no need to obtain the resultof an asymmetric cryptographic operation performed by the user'ssecurity device using the user's private key stored on that device. Thismeans that the authentication device may not need a digital connectioncapable of transferring to the server side (directly or indirectly)digital information e.g. provided by the user's security device such asdata cryptographically generated by the user's security device with theuser's private key (such as for example a signature or a response to achallenge). In some embodiments it may be sufficient for theauthentication device to have a unidirectional data input interface forreceiving the initialization message (such as for example a camera forcapturing images displayed on a computer screen). In some embodimentsthe initialization message is encoded in a signal that can be output bythe human output interface of the user's access device and theauthentication device has a data input interface adapted to capture thissignal. In such embodiments the authentication device can be remotelyinitialized using an access device that doesn't need any specifichardware or software interface to communicate with the user's securitydevice. For initializing the authentication device the access devicealso doesn't need any other interface, other than a standard humanoutput interface, to send digital data to the authentication device anddoesn't need any interface to receive data from the authenticationdevice. In some embodiments an authentication device may (for aparticular user's security device) have to receive an initializationmessage only infrequently. In some embodiments an authentication devicemay (for a particular user's security device) have to receive aninitialization message only once. In some embodiments the authenticationdevice's data input interface for receiving an initialization messagemay have a high data rate for ensuring rapid transfer of anyinitialization message which enhances the user convenience. In someembodiments, for example in cases where authentication devices need toreceive an initialization message only infrequently, the authenticationdevice's data input interface for receiving an initialization messagemay have a low data rate which may allow for cheap implementations andmay be acceptable for users in cases whereby receiving theinitialization message only needs to happen infrequently.

Advantages of encrypting parts of the initialization message with anauthentication device related key.

By encrypting parts of the initialization message with an authenticationdevice related key, one can ensure that only an authentication devicethat has access to the matching decryption key can decrypt and use theseparts. By thus encrypting parts of the initialization seed with anauthentication device related key whereby only one particularauthentication device or the authentication devices of a particulargroup have access to the corresponding decryption key, one can ensurethat only these targeted authentication devices can obtain theinitialization seed. That means that an attacker who manages tosurrepitiously intercept the initialization message and who may haveaccess at some point in time to the user's security device, may stillnot be able to obtain the initialization seed (e.g. for deriving the OTPgeneration key to fraudulently generate valid OTPs). This may inparticular be true if each authentication device has been personalizedwith its own unique value for the decryption key. In that case anyinitialization message is only usable with the particular authenticationdevice at which it was targeted. Anyone requesting an initializationmessage would have to identify his/her authentication device. If anattacker were requesting multiple initialization messages with the aimof using them with their own authentication device, then the attackerwould have to identify their authentication device. This could be usede.g. by fraud detection mechanisms to discover potential fraud attempts(for example if an abnormal number of initialization messages arerequested for the same authentication device or if an initializationmessage is requested for a blacklisted authentication device).

The invention allows for remote applications to be secured (by means ofOTPs and dynamic MACs over transaction data) whereby the security isbased on high security cryptographic protocols and more particulartaking advantage of the user's public-private key pair on the user'ssecurity device, without however requiring that the access device usedby the user to access the application is adapted to communicate with theuser's security device that holds the user's public-private key pair.Applications can be secured that don't offer any digital connection tothe user's security device or even the user's authentication device.

The foregoing has described several aspects or embodiments comprisingmethods or devices. In another aspect the invention comprises a sequenceof instructions recorded on a computer readable medium which, whenexecuted by a processor perform methods as already described. Softwaredelivery can also be effected over digital networks such as theInternet. Accordingly in still a further aspect the inventioncomprehends an information bearing signal which comprises a sequence ofinstructions which, when executed by a processor perform methods asalready described.

It should be emphasized that the term “comprises/comprising” when usedin this specification is taken to specify the presence of statedfeatures, steps, or components but does not preclude the presence oraddition of one or more other features, steps, components or groupsthereof.

While several embodiments of the invention have been described with someparticularity it should be understood that this description is exemplaryand not limiting; the scope of the invention is to be determined by theclaims appended hereto.

The invention claimed is:
 1. An authentication device for generatingdynamic credentials comprising: a memory component for storing a secretcredential generation key; a user input interface for receiving inputsfrom a user; a communication interface for communicating with a securitydevice of said user that stores a first private key of a firstpublic/private key pair associated with said user and that is adapted toperform asymmetric cryptographic calculations with said first privatekey wherein said asymmetric cryptographic calculations comprise at leastan asymmetric cryptographic decryption operation; a data input interfacefor receiving an initialization message comprising an initializationseed at least a first part of which is encrypted with said first publickey of said first public/private key pair; a hardware processingcomponent adapted to generate a dynamical credential using a symmetriccryptographic algorithm that cryptographically combines said secretcredential generation key with a dynamic variable; whereby theauthentication device is adapted to: extract at least said firstencrypted part of the initialization seed from the initializationmessage, submit, using the communication interface, to the securitydevice of said user the first encrypted part of the initialization seedfor the security device to decrypt said first encrypted part of theinitialization seed using said private key and said asymmetriccryptographic decryption operation, receive, using the communicationinterface, from the security device the first part of the initializationseed decrypted by the security device, derive the value of said secretcredential generation key from at least said decrypted first part of theinitialization seed; limit the life-time of the secret credentialgeneration key; determine whether the life-time of the secret credentialgeneration key has been exceeded; discard the secret credentialgeneration key after it has been determined that the life-time of thesecret credential generation key has been exceeded; store in the memorycomponent a data set associated with the secret credential generationkey that comprises a first regeneration value; regenerate the value ofthe secret credential generation key after it has been discarded,whereby the authentication device regenerating the value of the secretcredential generation key comprises; the authentication devicesubmitting to said user's security device said first regeneration valuefor said user's security device to process said first regeneration valuewith an asymmetric cryptographic algorithm using a second private key ofa second public/private key pair stored in the user's security device;receiving from the user's security device the resulting value of saidprocessing by the user's security device of the first regeneration valueusing said second private key; and deriving the value of the secretcredential generation key from said resulting value.
 2. Theauthentication device of claim 1 whereby the first encrypted part of theinitialization seed comprises the entire initialization seed.
 3. Theauthentication device of claim 2 whereby the initialization seedcomprises the secret credential generation key.
 4. The authenticationdevice of claim 1 whereby the life-time of the secret credentialgeneration key is based on the time elapsed since a particular event andthe authentication device is further adapted to discard the secretcredential generation key after a predetermined period of time haselapsed.
 5. The authentication device of claim 4 whereby the particularevent is when the secret credential generation key was derived by theauthentication device.
 6. The authentication device of claim 1 wherebythe life-time of the secret credential generation key is based on thenumber of times its current value has already been used for generatingdynamical credentials since that value was derived by the authenticationdevice.
 7. The authentication device of claim 6 further adapted to countthe number of times it has used the secret credential generation keyafter it has obtained its current value and to discard that value whenthat number exceeds a certain fixed threshold.
 8. The authenticationdevice of claim 7 further adapted to discard the secret credentialgeneration key after it has been used once for generating a dynamiccredential.
 9. The authentication device of claim 1 whereby thelife-time of the secret credential generation key is defined in terms ofcertain events.
 10. The authentication device of claim 9 further adaptedto require the presence of said security device for the generation ofdynamic credentials and to discard the secret credential generation keyupon removal of the security device.
 11. The authentication device ofclaim 1 whereby discarding the secret credential generation keycomprises erasing the value of the secret credential generation key fromthe memory component.
 12. The authentication device of claim 1 wherebysaid second public/private key pair is the same as said firstpublic/private key pair.
 13. The authentication device of claim 1whereby said first regeneration value comprises said first encryptedpart of the initialization seed.
 14. The authentication device of claim1, whereby said first regeneration value comprises the secret credentialgeneration key encrypted with the second public key corresponding tosaid second private key and regenerating the value of the secretcredential generation key comprises the authentication device submittingto said user's security device the encrypted secret credentialgeneration key for said user's security device to decrypt the encryptedsecret credential generation key using said second private key of saidsecond public/private key pair stored in the user's security device. 15.The authentication device of claim 1 whereby the authentication deviceregenerating the value of the secret credential generation key comprisesthe authentication device submitting to said user's security device thefirst encrypted part of the initialization seed for said user's securitydevice to decrypt the first encrypted part of the initialization seedusing said first private key of said first public/private key pairstored in the user's security device.
 16. The authentication device ofclaim 1 further adapted to determine the first regeneration value priorto discarding the secret credential generation key.
 17. Theauthentication device of claim 16 whereby determining the firstregeneration value comprises: determining a regeneration seed,encrypting said regeneration seed with the second public keycorresponding to said second private key, and including said encryptedregeneration seed in the first regeneration value; and wherebyregenerating the value of the secret credential generation keycomprises: the authentication device submitting to said user's securitydevice said first regeneration value for said user's security device todecrypt said first regeneration value with an asymmetric decryptionalgorithm using said second private key, and deriving the secret dynamiccredential generation key from the decrypted first regeneration value.18. The authentication device of claim 1 whereby said data setassociated with the secret credential generation key also comprises asecond regeneration value and the authentication device is furtheradapted to regenerate the secret credential generation value using saidsecond regeneration value and said resulting value of said processing bythe user's security device of the first regeneration value.
 19. Theauthentication device of claim 18 whereby the second regeneration valuecomprises a regeneration seed encrypted with a regeneration encryptionkey using a symmetric encryption algorithm.
 20. The authenticationdevice of claim 19 whereby the regeneration seed comprises theinitialization seed.
 21. The authentication device of claim 19 wherebythe regeneration seed comprises the secret credential generation key.22. The authentication device of claim 19 whereby regenerating thesecret credential generation key comprises: the authentication devicesubmitting the first regeneration value to the security device for thesecurity device to sign using an asymmetric signature algorithm and saidsecond private key, receiving the resulting signature, deriving theregeneration encryption key from said resulting signature, using thederived regeneration encryption key to decrypt with a symmetricdecryption algorithm the second regeneration value to obtain saidregeneration seed, and deriving the secret credential generation valuefrom the decrypted regeneration seed.
 23. The authentication device ofclaim 19 further adapted to determine the first regeneration value andthe second regeneration value prior to discarding the secret credentialgeneration key.
 24. The authentication device of claim 23 whereby theauthentication device determines the first regeneration value bychoosing a challenge and determines the second regeneration value bydetermining a regeneration seed and a regeneration encryption key andencrypting said regeneration seed with said regeneration encryption keyto obtain the second regeneration value, whereby the authenticationdevice determines the regeneration encryption key by submitting thefirst regeneration value to the security device for the security deviceto sign using an asymmetric signature algorithm and said second privatekey, receiving the resulting signature, deriving the regenerationencryption key from said resulting signature and whereby theregeneration seed is determined to be a value that is related to thesecret credential generation key such that the authentication device canderive the secret credential generation key from said regeneration seed.25. The authentication device of claim 1 further adapted to capture asignal that is output or emitted by an output interface of an accessdevice of the user and that encodes a representation of theinitialization message, and the authentication device may be furtheradapted to extract and decode the initialization message from thecaptured signal.
 26. The authentication device of claim 1, furthercomprising: a camera; and further adapted to take a picture with saidcamera of an image that encodes the initialization message and that isdisplayed on the display of said access device; and further adapted toextract the image from the picture taken with the camera and to decodethe image to obtain the initialization message encoded in the image. 27.The authentication device of claim 1 further comprising a clock toprovide a time value, and further adapted to use said time value todetermine the value of the dynamic variable.
 28. The authenticationdevice of claim 1 whereby the dynamic value is derived from a value thatis stored and maintained by the authentication device and that isupdated by the authentication device at certain events.
 29. Theauthentication device of claim 1 further adapted to derive the dynamicvariable from a challenge that is generated externally to theauthentication device and that is received by the authentication device.30. The authentication device of claim 1 further adapted to derive thedynamic variable from transaction data that represent a transaction thatthe user wants to submit to an application and that are received by theauthentication device.
 31. The authentication device of claim 1 furthercomprising a user output interface and further adapted to use said useroutput interface to communicate the generated dynamic credential to theuser.
 32. A method for generating a first dynamic credential by theauthentication device of claim 1 and a security device of a particularuser, the method comprising the steps of: initializing saidauthentication device of said particular user with a secret credentialgeneration key for generating dynamic credentials by: receiving from aserver at said authentication device an initialization message, theinitialization message comprising at least an encrypted first part of aninitialization seed and any other part of the initialization seed,whereby said first part of said initialization seed has been encryptedwith a first asymmetric encryption algorithm using a first public key ofa first public/private key pair; extracting at the authentication devicethe encrypted first part of the initialization seed and any other partof the initialization seed from the received initialization message;communicating at the authentication device with said security device ofsaid user presented to the authentication device by the user; submittingby the authentication device the encrypted first part of theinitialization seed to said security device; decrypting at said securitydevice the encrypted first part of the initialization seed with a firstprivate key of said first public/private key pair, the first private keystored on the security device, and returning the decrypted first part ofthe initialization seed to the authentication device; receiving at theauthentication device the decrypted first part of the initializationseed; deriving at the authentication device the secret credentialgeneration key from the initialization seed; the authentication deviceobtaining a value of a dynamic variable; the authentication devicedetermining said first dynamic credential as the result ofcryptographically combining said value of said dynamic variable withsaid secret credential generation key using a symmetric cryptographicdynamic credential generation algorithm; the authentication deviceverifying against a set of criteria whether the life-time of said secretcredential generation key has expired, the authentication device, ifsaid life-time has expired, discarding said secret credential generationkey; and the authentication device, prior to generating a second dynamiccredential using said secret credential generation key, regenerating thesecret credential generation key, the secret credential generation keyregenerated by: the authentication device requiring the presence of thesecurity device of the user and communicating with the security device,the authentication device submitting a first regeneration value to thesecurity device, the security device receiving said first regenerationvalue and using the received first regeneration value as input for asecond asymmetric cryptographic operation parameterized with a secondprivate key stored on the security device of a second public/private keypair associated with the user, the security device returning to theauthentication device the result of said second asymmetric cryptographicoperation by the security device, and the authentication device usingsaid result.
 33. The method of claim 32, further comprising: determiningat the server the secret credential generation key is a function of theinitialization seed; associating at the server the secret credentialgeneration key with said particular user; encrypting at the server atleast the first part of the initialization seed with said firstasymmetric encryption algorithm using said first public key of the firstpublic/private key pair; assembling at the server the initializationmessage comprising said encrypted first part of the initialization seedand any other part of the initialization seed; and sending saidinitialization message to said authentication device of said user. 34.The method of claim 33 comprising the additional steps of: encrypting atthe server at least a second part of the initialization seed using anencryption key that matches a decryption key known to the authenticationdevice and decrypting at the authentication device said second part ofthe initialization seed with said decryption key.
 35. The method ofclaim 34 whereby the value of said decryption key is unique to saidparticular authentication device.
 36. The method of claim 34 wherebysaid particular authentication device shares the value of saiddecryption key with at least one other authentication device.
 37. Themethod of claim 33 whereby: the step of sending said initializationmessage to said authentication device of said user comprises the serversending the initialization message to an access device of said user; andthe access device emitting over an output interface of the access devicea signal encoded with a representation of the initialization message,and the step of receiving at said authentication device theinitialization message comprises the authentication device capturingsaid signal and decoding said signal to obtain the representation ofsaid initialization message.
 38. The method of claim 37 whereby theauthentication device comprises a camera and the access device comprisesa display and the representation of the initialization message comprisesa two-dimensional image and the method comprises the additional steps ofthe access device displaying said two-dimensional image on the displayof the access device and the authentication device making a picture ofsaid image, extracting said two-dimensional image from said picture anddecoding the image to obtain the initialization message.
 39. The methodof claim 32 comprising the additional step of storing at leasttemporarily the derived secret credential generation key in a memorycomponent of the authentication device.
 40. The method of claim 32comprising the additional steps of: the authentication device generatinga representation of said generated dynamic credential that can bepresented to the user, and the authentication device presenting saidrepresentation to the user by means of an output interface of theauthentication device.
 41. The method of claim 32 wherein said secretcredential generation key is discarded after said generation of saidfirst dynamic credential.
 42. The method of claim 32 wherein saiddiscarding comprises the authentication device erasing the secretcredential generation key from a memory component of the authenticationdevice.
 43. The method of claim 32 wherein said discarding comprises theauthentication device inactivating the secret credential generation keystored in a memory component of the authentication device.
 44. Themethod of claim 32 wherein said using by the authentication device ofsaid result comprises the authentication device verifying said result.45. The method of claim 44 wherein: said second asymmetric cryptographicoperation by the security device comprises the generation of a signatureover the received first regeneration value with an asymmetriccryptographic signature algorithm parameterized with said second privatekey, said result comprises said signature, and said verification of saidresult by said authentication device comprises verifying said signaturecomprised in said result.
 46. The method of claim 45 wherein the firstregeneration value comprises a random challenge generated by theauthentication device.
 47. The method of claim 44 wherein discarding thesecret credential generation key by the authentication device maycomprise the authentication device inactivating the secret credentialgeneration key stored in a memory component of the authentication deviceand the usage by the authentication device of said result of saidasymmetric cryptographic operation by the security device may comprisereactivating the secret credential generation key stored in a memorycomponent of the authentication device if said verification of theresult was successful.
 48. The method of claim 32 wherein theauthentication device determines, prior to said discarding of the secretcredential generation key, an intermediate value, and said firstregeneration value comprises said intermediate value encrypted with asecond asymmetric encryption algorithm parameterized with a secondpublic key that corresponds to said second private key of said secondpublic/private key pair.
 49. The method of claim 48 wherein said secondasymmetric cryptographic operation by the security device comprises thedecryption of the received first regeneration value with a secondasymmetric decryption algorithm parameterized with said second privatekey, said result comprises the decrypted intermediate value, and theusage by the authentication device of said result comprises theauthentication device using the decrypted intermediate value to obtainthe value of the secret credential generation key.
 50. The method ofclaim 49 wherein the intermediate value comprises the secret credentialgeneration key.
 51. The method of claim 49 wherein the intermediatevalue comprises the initialization key.
 52. The method of claim 32wherein the authentication device determines, prior to said discardingof the secret credential generation key, a second regeneration value,and the usage by the authentication device of said result of said secondasymmetric cryptographic operation by the security device comprises theauthentication device mathematically or cryptographically combining saidsecond regeneration value with said result to determine the value of thesecret credential generation key.
 53. The method of claim 52 whereinsaid determination of the second regeneration value comprisesdetermining an intermediate regeneration seed and encrypting theintermediate regeneration seed with an intermediate encryption key, andthe second regeneration value comprises the intermediate regenerationseed encrypted with the intermediate encryption key, and the usage bythe authentication device of said result of said second asymmetriccryptographic operation by the security device comprises deriving fromsaid result an intermediate decryption key that matches saidintermediate encryption key and decrypting said encrypted intermediateregeneration seed and deriving the value of the secret credentialgeneration key from the decrypted intermediate regeneration seed. 54.The method of claim 53 wherein the intermediate regeneration seedcomprises the secrete credential generation key.
 55. The method of claim53 wherein the intermediate regeneration seed comprises theinitialization seed.
 56. The method of claim 53 wherein theauthentication device determines the value of the intermediatedecryption key and determines said first regeneration value byencrypting the intermediate decryption key with said second public keyand the authentication device recovers the intermediate decryption keyby submitting the first regeneration value to the security device to bedecrypted by the second private key.
 57. The method of claim 53 whereinthe authentication device determines the first regeneration value, anddetermines the value of the intermediate encryption key a first time bysubmitting the first regeneration value to the security device to besigned by the second private key and deriving the intermediateencryption key from the resulting signature, uses the intermediateencryption key to determine the second regeneration value by encryptingthe intermediate regeneration seed with the intermediate encryption keyas described above, stores the first regeneration value and the secondregeneration value, and regenerates the secret credential generation keyas described above by regenerating the intermediate encryption key byre-submitting the first regeneration value to the security device to besigned by the second private key and re-deriving the intermediateencryption key from the resulting signature and using the regeneratedintermediate encryption key to decrypt the second regeneration value toobtain the value of the intermediate regeneration seed, and derives thesecret credential generation key from the obtained value of theintermediate regeneration seed.
 58. A method for securing an interactionbetween a user and a remote application server using an authenticationdevice of the user, the method comprising the steps of: receiving at theapplication server a request of the user; generating at theauthentication device at the request of the user a dynamic credentialaccording to the method of claim 32; making available to a verificationserver the secret dynamic credential generation key associated with theuser; receiving the generated dynamic credential at the verificationserver; verifying at the verification server the validity of thereceived dynamic credential using said secret dynamic credentialgeneration key; and, if the received dynamic credential is verified tobe valid, granting at the remote application server said request.